BR112017018956B1 - FILE FORMAT BASED STREAMING WITH LCT BASED DASH FORMATS - Google Patents

Abstract

Em um exemplo, um dispositivo inclui um ou mais decodificadores de mídia configurados para decodificar os dados de mídia, uma interface de rede configurada para receber uma Descrição de Instância de Sessão (LSID) de transporte de codificação em camadas (LCT), a LSID incluindo informação representando uma pluralidade de sessões LCT, cada uma das sessões LCT incluindo dados de uma representação respectiva dentre uma pluralidade de representações de uma apresentação de mídia DASH e dados de uma ou mais das sessões LCT, e um processador configurado para iniciar o consumo da uma ou mais representações da apresentação de mídia DASH utilizando a LSID e sem usar um arquivo de manifesto para a apresentação de mídia DASH, em que para iniciar o consumo, o processador é configurado para receber, por intermédio da interface de rede, pacotes das sessões LCT incluindo porções de dados da uma ou mais das representações; e proporcionar os dados dos pacotes para um ou mais decodificadores de mídia.In an example, a device includes one or more media decoders configured to decode media data, a network interface configured to receive a Layered Coding Transport (LCT) Session Instance Description (LSID), the LSID including information representing a plurality of LCT sessions, each of the LCT sessions including data from a respective representation of a plurality of representations of a DASH media presentation and data from one or more of the LCT sessions, and a processor configured to initiate consumption of the one or more representations of the DASH media presentation using the LSID and without using a manifest file for the DASH media presentation, where to initiate consumption, the processor is configured to receive, via the network interface, packets from the LCT sessions including portions of data from one or more of the representations; and providing the packet data to one or more media decoders.

Description

[0001] Esse pedido reivindica o benefício do Pedido Provisional dos Estados Unidos N° 62/128.380, depositado em 4 de março de 2015, e Pedido Provisional dos Estados Unidos N° 62/128.943, depositado em 5 de março de 2015, os conteúdos integrais de cada um dos quais são aqui incorporados mediante referência.[0001] This application claims the benefit of United States Provisional Application No. 62/128,380, filed on March 4, 2015, and United States Provisional Application No. 62/128,943, filed on March 5, 2015, the contents integral parts of each of which are incorporated herein by reference.

CAMPO TÉCNICOTECHNICAL FIELD

[0002] Essa revelação se refere ao armazenamento e transporte de dados de vídeo codificados.[0002] This disclosure relates to the storage and transport of encoded video data.

ANTECEDENTESBACKGROUND

[0003] As capacidades de vídeo digital podem ser incorporadas em uma ampla gama de dispositivos, incluindo televisões digitais, sistemas de difusão direta digital, sistemas de difusão sem fio, assistentes pessoais digitais (PDAs), computadores de mesa ou laptop, câmeras digitais, dispositivos de gravação digital, aparelhos de reprodução de mídia digital, dispositivo de jogos de vídeo, consoles de jogos de vídeo, telefones de rádio via satélite ou celulares, dispositivos de teleconferência de vídeo, e semelhantes. Os dispositivos de vídeo digital implementam técnicas de compactação de vídeo, tais como aquelas descritas no padrão definido por MPEG2, MPEG4, ITU-T H.263 ou ITU-T H.264/MPEG4, Parte 10, Codificação Avançada de Vídeo (AVC), ITU-TH. 265/MPEG-H Parte 2 (também referida como Codificação de Vídeo de Alta Eficiência (HEVC)), e extensões de tais padrões, para transmitir e receber mais eficientemente a informação de vídeo digital.[0003] Digital video capabilities can be incorporated into a wide range of devices, including digital televisions, digital direct broadcast systems, wireless broadcast systems, personal digital assistants (PDAs), desktop or laptop computers, digital cameras, digital recording devices, digital media playback apparatus, video gaming device, video game consoles, satellite radio or cellular telephones, video teleconferencing devices, and the like. Digital video devices implement video compression techniques such as those described in the standard defined by MPEG2, MPEG4, ITU-T H.263, or ITU-T H.264/MPEG4, Part 10, Advanced Video Coding (AVC) , ITU-TH. 265/MPEG-H Part 2 (also referred to as High Efficiency Video Coding (HEVC)), and extensions of such standards, to more efficiently transmit and receive digital video information.

[0004] As técnicas de compactação de vídeo realizam predição espacial e/ou predição temporal para reduzir ou remover redundância inerente nas sequencias de vídeo. Para codificação de vídeo baseada em bloco, um quadro ou partição de vídeo pode ser dividido em macro blocos. Cada macro bloco pode ser adicionalmente dividido. Os macro blocos em um quadro ou partição intra-codificada (I, são codificados utilizando predição espacial com relação aos macro blocos adjacentes. Os macro blocos em um quadro ou partição inter-codificada (P ou B) pode usar predição espacial com relação aos macro blocos adjacentes no mesmo quadro ou partição ou predição temporal com relação a outros quadros de referência.[0004] Video compression techniques perform spatial prediction and/or temporal prediction to reduce or remove redundancy inherent in video sequences. For block-based video encoding, a video frame or partition can be divided into macro blocks. Each macro block can be further divided. Macro blocks in an intra-coded frame or partition (I, are coded using spatial prediction with respect to adjacent macro blocks. Macro blocks in an inter-coded frame or partition (P or B) may use spatial prediction with respect to macros adjacent blocks in the same frame or partition or temporal prediction with respect to other frames of reference.

[0005] Após os dados de vídeo terem sido codificados, os dados de vídeo podem ser empacotados para a transmissão ou armazenamento. Os dados de vídeo podem ser montados em um arquivo de vídeo em conformidade com qualquer um de uma variedade de padrões, tal como o formato de arquivo de mídia de base International Organization of Standardization (ISO) e suas extensões, tal como AVC.[0005] After the video data has been encoded, the video data can be packaged for transmission or storage. Video data can be assembled into a video file conforming to any of a variety of standards, such as the International Organization of Standardization (ISO) base media file format and its extensions, such as AVC.

SUMÁRIOSUMMARY

[0006] Em geral, essa revelação descreve várias técnicas para acessar os dados de mídia de uma ou mais representações transportadas mediante transporte de codificação em camadas (LCT) sem usar um arquivo de manifesto, tal como uma descrição de apresentação de mídia (MPD) para as representações. Por exemplo, uma Descrição de Instância de Sessão LCT (LSID) pode incluir pelo menos alguns dos dados de arquivo de manifesto usados para inicialização e/ou operação contínua de um serviço para acessar os dados de mídia. Por exemplo, a LSID pode incluir informação indicando propriedades das representações. Adicionalmente ou alternativamente, pacotes das sessões LCT podem incluir cabeçalhos LCT com dados atribuídos que indicam como os pacotes se relacionam aos segmentos das representações, por exemplo, quais pacotes correspondem a cada segmento. Dessa maneira, um dispositivo de cliente pode iniciar o consumo de uma ou mais das representações sem (ou antes) receber o arquivo de manifesto.[0006] In general, this disclosure describes various techniques for accessing media data from one or more representations carried via layered coding transport (LCT) without using a manifest file, such as a media presentation description (MPD). for representations. For example, an LCT Session Instance Description (LSID) may include at least some of the manifest file data used for initialization and/or continued operation of a service to access media data. For example, the LSID may include information indicating properties of the representations. Additionally or alternatively, LCT session packets may include LCT headers with assigned data that indicate how the packets relate to segments of the representations, e.g., which packets correspond to each segment. In this way, a client device can start consuming one or more of the representations without (or before) receiving the manifest file.

[0007] Em um exemplo, o método de receber os dados de mídia inclui determinar uma pluralidade de representações de uma apresentação de mídia de fluxo contínuo adaptável dinâmico sobre HTTP (DASH) a partir de uma Descrição de Instância de Sessão de transporte de codificação em camadas (LCT) (LSID), em que a LSID inclui informação representativa de uma pluralidade de sessões LCT, cada uma das sessões LCT incluindo dados de uma representação respectiva dentre as representações, e iniciando o consumo de uma ou mais das representações da apresentação de mídia DASH utilizando a LSID e sem usar um arquivo de manifesto para a apresentação de mídia DASH, em que o consumo de iniciação compreende receber os pacotes das sessões LCT incluindo porções de dados da uma ou mais dentre as representações, e proporcionando dados dos pacotes para um decodificador de mídia.[0007] In one example, the method of receiving the media data includes determining a plurality of representations of a dynamic adaptive streaming media presentation over HTTP (DASH) from an encoding transport Session Instance Description in (LCT) layers (LSID), wherein the LSID includes information representative of a plurality of LCT sessions, each of the LCT sessions including data from a respective representation among the representations, and initiating consumption of one or more of the representations of the presentation of DASH media using the LSID and without using a manifest file for the presentation of DASH media, wherein the initiation consumption comprises receiving the packets from the LCT sessions including data portions of the one or more of the representations, and providing data from the packets to a media decoder.

[0008] Em outro exemplo, um dispositivo para receber os dados de mídia inclui um ou mais decodificadores de mídia configurados para decodificar os dados de mídia, uma interface de rede configurada para receber uma descrição de instância de sessão de transporte de codificação em camadas (LCT), LSID, em que a LSID inclui informação representativa de uma pluralidade de sessões LCT, cada uma das sessões LCT incluindo dados de uma representação respectiva dentre uma pluralidade de representações de uma apresentação de mídia de Fluxo Contínuo Adaptável Dinâmico sobre HTTP (DASH) e dados de uma ou mais das sessões LCT, e um processador configurado para iniciar o consumo de uma ou mais das representações da apresentação de mídia DASH utilizando a LSID e sem usar um arquivo de manifesto para a apresentação de mídia DASH, em que para iniciar o consumo, o processador é configurado para receber, por intermédio da interface de rede, pacotes das sessões LCT incluindo porções de dados da uma ou mais das representações, e proporcionar dados dos pacotes para um ou mais decodificadores de vídeo.[0008] In another example, a device for receiving the media data includes one or more media decoders configured to decode the media data, a network interface configured to receive a layered encoding transport session instance description ( LCT), LSID, wherein the LSID includes information representative of a plurality of LCT sessions, each of the LCT sessions including data from a respective representation of a plurality of representations of a Dynamic Adaptive Streaming over HTTP (DASH) media presentation and data from one or more of the LCT sessions, and a processor configured to initiate consumption of one or more of the DASH media presentation representations using the LSID and without using a manifest file for the DASH media presentation, where to initiate consumption, the processor is configured to receive, via the network interface, packets from the LCT sessions including portions of data from the one or more of the representations, and provide data from the packets to one or more video decoders.

[0009] Em outro exemplo, um dispositivo para receber os dados de mídia inclui meios para determinar uma pluralidade de representações de uma apresentação de mídia de Fluxo Contínuo Adaptável Dinâmico sobre HTTP (DASH) a partir de uma descrição de instância de sessão de transporte de codificação em camadas (LCT), LSID,, em que a LSID inclui informação representativa de uma pluralidade de sessões LCT cada uma das sessões LCT incluindo dados de uma representação respectiva das representações, e meios para iniciar o consumo de uma ou mais das representações da apresentação de mídia DASH utilizando a LSID e sem usar um arquivo de manifesto para a apresentação de mídia DASH, em que os meios para iniciação de consumo compreendem meios para receber pacotes das sessões LCT incluindo porções de dados da uma ou mais das representações, e meios para proporcionar dados dos pacotes para um decodificador de mídia.[0009] In another example, a device for receiving media data includes means for determining a plurality of representations of a Dynamic Adaptive Streaming over HTTP (DASH) media presentation from a transport session instance description. layered coding (LCT), LSID, wherein the LSID includes information representative of a plurality of LCT sessions, each of the LCT sessions including data from a respective representation of the representations, and means for initiating consumption of one or more of the representations of the presenting DASH media using the LSID and without using a manifest file for presenting DASH media, wherein the means for initiating consumption comprises means for receiving packets from the LCT sessions including portions of data from the one or more of the representations, and means to provide packet data to a media decoder.

[0010] Em outro exemplo, um meio de armazenamento legível por computador tem nele armazenadas instruções que, quando executadas, fazem com que um processador de um dispositivo para receber os dados de mídia determine uma pluralidade de representações de uma apresentação de mídia de Fluxo Contínuo Adaptável Dinâmico sobre HTTP (DASH) a partir de uma Descrição de Instância de Sessão de transporte de codificação em camadas (LCT), LSID, em que a LSID inclui informação representativa de uma pluralidade de sessões LCT, cada uma das sessões LCT incluindo dados de uma representação respectiva dentre as representações, e iniciar o consumo de uma ou mais das representações da apresentação de mídia DASH utilizando a LSID e sem usar um arquivo de manifesto para a apresentação de mídia DASH, em que as instruções que fazem com que o processador inicie o consumo compreendem instruções que fazem com que o processador receba pacotes das sessões LCT incluindo porções de dados de uma ou mais das representações, e proporcione dados dos pacotes para um decodificador de mídia.[0010] In another example, a computer-readable storage medium has instructions stored therein that, when executed, cause a processor of a device for receiving the media data to determine a plurality of representations of a Streaming media presentation. Dynamic Adaptive over HTTP (DASH) from a layered coding transport (LCT) Session Instance Description, LSID, wherein the LSID includes information representative of a plurality of LCT sessions, each of the LCT sessions including data from a respective representation among the representations, and initiate consumption of one or more of the DASH media presentation representations using the LSID and without using a manifest file for the DASH media presentation, wherein the instructions that cause the processor to start consumption comprises instructions that cause the processor to receive packets from LCT sessions including data portions of one or more of the representations, and provide data from the packets to a media decoder.

[0011] Em outro exemplo, um método de enviar os dados de mídia inclui construir uma Descrição de Instância de Sessão de transporte de codificação em camadas (LCT), LSID, incluindo informação representativa de uma pluralidade de sessões LCT, cada uma das sessões LCT incluindo os dados de uma representação respectiva dentre uma pluralidade de representações de uma apresentação de mídia de Fluxo Contínuo Adaptável Dinâmico sobre HTTP (DASH), em que a LSID indica correspondências entre as sessões LCT e as representações, emitindo a LSID, e emitindo os dados das representações nas sessões LCT correspondentes.[0011] In another example, a method of sending the media data includes constructing a Layered Coding Transport (LCT) Session Instance Description, LSID, including information representative of a plurality of LCT sessions, each of the LCT sessions including the data of a respective representation among a plurality of representations of a Dynamic Adaptive Streaming over HTTP (DASH) media presentation, wherein the LSID indicates correspondences between the LCT sessions and the representations, outputting the LSID, and outputting the data representations in the corresponding LCT sessions.

[0012] Em outro exemplo, um dispositivo para envio de dados de mídia inclui uma interface de rede para emitir os dados a partir de uma pluralidade de sessões de transporte de codificação em camadas (LCT), e um processador configurado para construir uma Descrição de Instância de Sessão LCT (LSID) incluindo informação representativa de uma pluralidade de sessões LCT, cada uma das sessões LCT incluindo os dados de uma representação respectiva de uma pluralidade de representações de uma apresentação de mídia de Fluxo Contínuo Adaptável Dinâmico sobre HTTP (DASH), em que a LSID indica correspondências entre a sessão LCT e as representações, emite a LSID por intermédio da interface de rede, e emite os dados das representações nas sessões correspondentes LCT por intermédio da interface de rede.[0012] In another example, a device for sending media data includes a network interface for outputting the data from a plurality of layered coding transport (LCT) sessions, and a processor configured to construct a Media Description. LCT Session Instance (LSID) including information representative of a plurality of LCT sessions, each of the LCT sessions including the data of a respective representation of a plurality of representations of a Dynamic Adaptive Streaming over HTTP (DASH) media presentation, wherein the LSID indicates correspondences between the LCT session and the representations, outputs the LSID through the network interface, and outputs the representations data into the corresponding LCT sessions through the network interface.

[0013] Em outro exemplo, um dispositivo para enviar os dados de mídia inclui meios para construir uma descrição de instância de sessão de transporte de codificação em camadas (LCT), LSID incluindo informação representativa de uma pluralidade de sessões LCT, cada uma das sessões LCT incluindo dados de uma representação respectiva de uma pluralidade de representações de uma apresentação de mídia de Fluxo Contínuo Adaptável Dinâmico sobre HTTP (DASH), em que a LSID indica correspondências entre as sessões LCT e as representações, meios para emitir a LSID, e meios para emitir os dados das representações nas sessões LCT correspondentes.[0013] In another example, a device for sending the media data includes means for constructing a layered coding transport (LCT) session instance description, LSID including information representative of a plurality of LCT sessions, each of the sessions LCT including data from a respective representation of a plurality of representations of a Dynamic Adaptive Streaming over HTTP (DASH) media presentation, wherein the LSID indicates correspondences between the LCT sessions and the representations, means for issuing the LSID, and means to output the data from the representations in the corresponding LCT sessions.

[0014] Em outro exemplo, um meio de armazenamento legível por computador tem nele armazenadas instruções que, quando executadas, fazem com que um processador de um dispositivo para envio de dados de mídia construa uma Descrição de Instância de Sessão de transporte de codificação em camadas (LCT), (LSID), incluindo informação representativa de uma pluralidade de sessões LCT, cada uma das sessões LCT incluindo os dados de uma representação respectiva dentre uma pluralidade de representações de uma apresentação de mídia de fluxo contínuo adaptável dinâmico sobre HTTP (DASH) em que a LSID indica correspondências entre as sessões LCT e as representações, emite a LSID, e emite os dados das representações nas sessões correspondentes LCT.[0014] In another example, a computer-readable storage medium has instructions stored therein that, when executed, cause a processor of a device for sending media data to construct a layered encoding transport Session Instance Description (LCT), (LSID), including information representative of a plurality of LCT sessions, each of the LCT sessions including the data of a respective representation of a plurality of representations of a dynamic adaptive streaming media presentation over HTTP (DASH) wherein the LSID indicates correspondences between the LCT sessions and the representations, outputs the LSID, and outputs the data from the representations in the corresponding LCT sessions.

BREVE DESCRIÇÃO DOS DESENHOSBRIEF DESCRIPTION OF THE DRAWINGS

[0015] A figura 1 é um diagrama de blocos que ilustra um sistema exemplar que implementa as técnicas para fluxo contínuo de dados de mídia através de uma rede.[0015] Figure 1 is a block diagram illustrating an exemplary system that implements techniques for continuous flow of media data across a network.

[0016] A figura 2 é um diagrama conceitual que ilustra os elementos de conteúdo de multimídia exemplar.[0016] Figure 2 is a conceptual diagram illustrating exemplary multimedia content elements.

[0017] A figura 3 é um diagrama de blocos que ilustra os elementos de um arquivo de vídeo exemplar, que pode corresponder a um segmento de uma representação.[0017] Figure 3 is a block diagram illustrating the elements of an exemplary video file, which may correspond to a segment of a representation.

[0018] A figura 4 é um diagrama conceitual que ilustra um cenário exemplar que surge frequentemente em entrega de difusão.[0018] Figure 4 is a conceptual diagram illustrating an exemplary scenario that frequently arises in broadcast delivery.

[0019] A figura 5 é um diagrama conceitual que ilustra um sistema exemplar que pode realizar as técnicas dessa revelação.[0019] Figure 5 is a conceptual diagram illustrating an exemplary system that can perform the techniques of this disclosure.

[0020] A figura 6 é um diagrama conceitual que ilustra um sistema exemplar que pode realizar as técnicas dessa revelação.[0020] Figure 6 is a conceptual diagram illustrating an exemplary system that can perform the techniques of this disclosure.

[0021] A figura 7 é um diagrama conceitual que mostra diferentes aspectos da entrada de serviço no exemplo de DASH sobre FLUTE.[0021] Figure 7 is a conceptual diagram showing different aspects of the service input in the DASH over FLUTE example.

[0022] A figura 8 é um diagrama conceitual que mostra diferentes aspectos da entrada de serviço para um exemplo de DASH sobre ROUTE.[0022] Figure 8 is a conceptual diagram showing different aspects of the service input for an example of DASH over ROUTE.

[0023] A figura 9 é um diagrama conceitual que ilustra um conjunto exemplar de campos de cabeçalho de acordo com RFC 5651 que podem ser usados para transportar dados de acordo com as técnicas dessa revelação.[0023] Figure 9 is a conceptual diagram illustrating an exemplary set of header fields in accordance with RFC 5651 that can be used to transport data in accordance with the techniques of this disclosure.

[0024] A figura 10 é um diagrama conceitual que ilustra várias opções para sinalização quando um prefixo de um objeto pode ser liberado para a próxima camada para decodificação.[0024] Figure 10 is a conceptual diagram illustrating various options for signaling when an object prefix can be released to the next layer for decoding.

[0025] A figura 11 é um diagrama conceitual que ilustra modelos exemplares para recebimento de dados.[0025] Figure 11 is a conceptual diagram that illustrates exemplary models for receiving data.

[0026] A figura 12 é um diagrama conceitual que ilustra um sistema exemplar para receber os dados de mídia.[0026] Figure 12 is a conceptual diagram illustrating an exemplary system for receiving media data.

[0027] A figura 13 é um diagrama conceitual que ilustra um procedimento de envio exemplar.[0027] Figure 13 is a conceptual diagram illustrating an exemplary shipping procedure.

[0028] A figura 14 é um diagrama conceitual que ilustra um modelo de cliente DASH híbrido exemplar.[0028] Figure 14 is a conceptual diagram illustrating an exemplary hybrid DASH client model.

[0029] A figura 15 é um fluxograma que ilustra um método exemplar para o transporte de dados de mídia de uma representação de mídia por intermédio de sessões LCT de acordo com as técnicas dessa revelação.[0029] Figure 15 is a flowchart illustrating an exemplary method for transporting media data from a media representation through LCT sessions in accordance with the techniques of this disclosure.

[0030] A figura 16 é um fluxograma que ilustra outro método exemplar para o transporte de dados de mídia de uma representação de mídia por intermédio de sessões LCT de acordo com as técnicas dessa revelação.[0030] Figure 16 is a flowchart illustrating another exemplary method for transporting media data from a media representation through LCT sessions in accordance with the techniques of this disclosure.

[0031] A figura 17 é um fluxograma que ilustra outro método exemplar para o transporte de dados de mídia de uma apresentação de mídia por intermédio de sessões LCT de acordo com as técnicas dessa revelação.[0031] Figure 17 is a flowchart illustrating another exemplary method for transporting media data from a media presentation through LCT sessions in accordance with the techniques of this disclosure.

DESCRIÇÃO DETALHADADETAILED DESCRIPTION

[0032] De um modo geral, esta revelação descreve técnicas que permitem a capacidade para utilizar um protocolo unidirecional, por exemplo, envio de arquivos protocolo unidirecional, por exemplo, transporte unidirecional sobre entrega de arquivo (FLUTE), transporte unidirecional sobre entrega de objeto em tempo real (ROUTE), ou entrega de objeto para código de camada assíncrona e protocolos de multidifusão confiáveis NACK- Orientados (FCAST), assim como segmentos em fluxo contínuo adaptado dinamicamente sobre HTTP (DASH) com base no formato de arquivo de mídia de baseado em ISO (ISO BMFF) e possivelmente também outros formatos, como o fluxo de transporte (TS) MPEG-2 , a fim de criar um sistema de entrega de mídia de difusão baseado em IP que suporta entrega e reprodução de fluxo de mídia que: • Devem ser sincronizados entre si (tratados por ISO BMFF). • Devem ser aleatoriamente acessados (tratados por sinalização específica no protocolo de entrega). • Devem ser reproduzidos de tal modo que nenhum novo armazenamento e paralização ocorram. • Devem ser combinados com fluxos de mídia que sejam fornecidos e disponíveis na banda larga e unidifusão. • Permitam a entrega de múltiplos programas e multiplexação. • Habilitem baixos atrasos de inicialização e rápidas mudanças de canal. • Habilitem emenda de conteúdo no transmissor e no receptor. • E forneçam todos os recursos de DASH em um sistema de distribuição de difusão.[0032] Generally speaking, this disclosure describes techniques that enable the ability to utilize a unidirectional protocol, e.g., unidirectional protocol file sending, e.g., unidirectional transport over file delivery (FLUTE), unidirectional transport over object delivery real-time (ROUTE), or object delivery for asynchronous layer code and NACK-Oriented Reliable Multicast Protocols (FCAST), as well as dynamically adapted streaming segments over HTTP (DASH) based on the media file format of based on ISO (ISO BMFF) and possibly also other formats such as MPEG-2 transport stream (TS) in order to create an IP-based broadcast media delivery system that supports media stream delivery and playback that : • They must be synchronized with each other (treated by ISO BMFF). • They must be randomly accessed (handled by specific signaling in the delivery protocol). • They must be reproduced in such a way that no new storage and downtime occur. • Must be combined with media streams that are delivered and available on broadband and unicast. • Allow delivery of multiple programs and multiplexing. • Enable low startup delays and fast channel changes. • Enable content splicing at the transmitter and receiver. • And provide all DASH capabilities in a broadcast distribution system.

[0033] Mais particularmente, as técnicas desta revelação permitem a recepção de dados de mídia de uma ou mais representações através de sessões de Transporte de Codificação em Camadas (LCT), sem (ou antes) receber um arquivo de manifesto (tal como uma descrição de apresentação de mídia (MPD)) para as representações. Deste modo, as técnicas da presente revelação podem reduzir a latência associada com o início do consumo dos dados de mídia (por exemplo, executar o arranque serviço). Ou seja, ausente estas técnicas, um dispositivo de cliente precisaria aguardar a recepção do arquivo de manifesto, que pode causar má experiência do usuário (por exemplo, a visualização de uma tela preta e/ou ouvir qualquer reprodução de áudio). Usando estas técnicas podem reduzir a latência, de tal modo que a experiência do usuário pode ser melhorada (por exemplo, permitindo uma reprodução mais rápida de dados de áudio e/ou vídeo).[0033] More particularly, the techniques of this disclosure allow for the reception of media data from one or more representations through Layered Coding Transport (LCT) sessions, without (or before) receiving a manifest file (such as a description presentation format (MPD)) for the representations. In this way, the techniques of the present disclosure can reduce the latency associated with initiating consumption of the media data (e.g., running the startup service). In other words, absent these techniques, a client device would need to wait to receive the manifest file, which can cause poor user experience (e.g., seeing a black screen and/or hearing any audio playback). Using these techniques can reduce latency such that the user experience can be improved (for example, allowing faster playback of audio and/or video data).

[0034] As técnicas desta revelação podem ser aplicadas aos arquivos de vídeo em conformidade com os dados de vídeo encapsulados de acordo com qualquer um dos formatos de arquivo de mídia com base em ISO, os formatos de arquivo de código de vídeo escalonável (SVC), código de vídeo avançado(AVC), projeto de parceria de terceira geração (3GPP), e/ou código de vídeo de multivizualização (MVC) ou outros formatos de arquivos de vídeo semelhantes. Ou seja, segmentos de representações podem ser formados de acordo com qualquer um destes vários formatos. Em geral, os segmentos representam arquivos de mídia de forma independente a receber das representações correspondentes.[0034] The techniques of this disclosure can be applied to video files conforming to video data encapsulated in accordance with any of the ISO-based media file formats, the scalable video code (SVC) file formats , advanced video code (AVC), third generation partnership project (3GPP), and/or multi-view video code (MVC) or other similar video file formats. That is, segments of representations can be formed according to any of these various formats. In general, segments represent media files independently of receiving corresponding representations.

[0035] Em fluxo contínuo de HTTP, operações mais frequentes incluem HEAD, GET, e GET parcial. A operação HEAD recupera um cabeçalho de um arquivo associado a um determinado localizador uniforme de recursos (URL) ou nome uniforme de recursos (URN), sem recuperar uma carga útil associada com o URL ou URN. A operação GET recupera um arquivo inteiro associado a um determinado URL ou URN. A operação parcial GET recebe um intervalo de bytes como um parâmetro de entrada e recupera uma série contínua de bytes de um arquivo, onde o número de bytes corresponde ao intervalo de bytes recebido. Assim, fragmentos de filmes podem ser fornecidos para fluxo contínuo HTTP, porque uma operação GET parcial pode obter um ou mais fragmentos de filmes individuais. Em um fragmento de filme, pode haver vários fragmentos de trilha de diferentes trilhas. Em fluxo contínuo HTTP, uma apresentação de mídia pode ser uma coleção estruturada de dados que é acessível ao cliente. O cliente pode solicitar e baixar informações de dados de mídia para apresentar um serviço de fluxo contínuo para um usuário.[0035] In HTTP streaming, most frequent operations include HEAD, GET, and partial GET. The HEAD operation retrieves a header from a file associated with a given uniform resource locator (URL) or uniform resource name (URN), without retrieving a payload associated with the URL or URN. The GET operation retrieves an entire file associated with a given URL or URN. The GET partial operation takes a byte range as an input parameter and retrieves a continuous series of bytes from a file, where the number of bytes corresponds to the received byte range. Thus, movie fragments can be provided for HTTP streaming, because a partial GET operation can obtain one or more individual movie fragments. In a film fragment, there may be several track fragments from different tracks. In HTTP streaming, a media presentation can be a structured collection of data that is accessible to the client. The client may request and download media data information to present a streaming service to a user.

[0036] No exemplo de fluxo contínuo de dados 3 GPP usando fluxo contínuo de HTTP, pode haver múltiplas representações para dados de vídeo e/ou áudio de conteúdo de multimídia. Conforme explicado abaixo, diferentes representações podem corresponder a diferentes características de codificação (por exemplo, diferentes perfis ou níveis de um padrão de codificação de vídeo), padrões de codificação diferentes extensões ou de padrões de codificação (tais como extensões de múltiplas vistas e/ou escaláveis), ou taxas de bits diferentes. O manifesto de tais representações pode ser definido em uma estrutura de dados de descrição de apresentação de mídia (MPD). A apresentação de mídia pode corresponder a um conjunto estruturado de dados que é acessível a um dispositivo de cliente de fluxo contínuo HTTP. O dispositivo de cliente de fluxo contínuo HTTP pode solicitar e baixar informações de dados de mídia para apresentar um serviço de fluxo contínuo para um usuário do dispositivo de cliente. Uma apresentação de mídia pode ser descrita na estrutura de dados de MPD, que pode incluir mais de MPD.[0036] In the example of 3 GPP streaming data using HTTP streaming, there may be multiple representations for video and/or audio data of multimedia content. As explained below, different representations may correspond to different encoding characteristics (e.g., different profiles or levels of a video encoding standard), different encoding standards or extensions of encoding standards (such as multi-view extensions and/or scalable), or different bitrates. The manifest of such representations can be defined in a media presentation description (MPD) data structure. The media presentation can correspond to a structured set of data that is accessible to an HTTP streaming client device. The HTTP streaming client device may request and download media data information to present a streaming service to a user of the client device. A media presentation can be described in the MPD data structure, which can include more than MPD.

[0037] Uma apresentação de mídia pode conter uma sequência de um ou mais períodos. Períodos podem ser definidos por um elemento Período no MPD. Cada período pode ter um início atributo no MPD. O MPD pode incluir um atributo início e um atributo availableStartTime para cada período. Para serviços ao vivo, a soma do atributo início do período e o atributo MPD availableStartTime pode especificar o tempo de disponibilidade do período no formato UTC, em particular, o primeiro segmento de mídia de cada representação no período correspondente. Para serviços sob demanda, o atributo início do primeiro período pode ser 0. Para qualquer outro período, o atributo início pode especificar um deslocamento entre a hora de início do período correspondente em relação à hora de início do primeiro período de tempo. Cada período pode estender-se até o início do próximo período, ou até o final da apresentação mídia no caso do último período. Tempos de início de período podem ser precisos. Eles podem refletir o tempo real resultante de reproduzir a mídia de todos os períodos anteriores.[0037] A media presentation may contain a sequence of one or more periods. Periods can be defined by a Period element in the MPD. Each period can have a start attribute in the MPD. The MPD can include a start attribute and an availableStartTime attribute for each period. For live services, the sum of the period start attribute and the MPD availableStartTime attribute can specify the period availability time in UTC format, in particular, the first media segment of each representation in the corresponding period. For on-demand services, the start attribute of the first time period can be 0. For any other time period, the start attribute can specify an offset between the start time of the corresponding period relative to the start time of the first time period. Each period can extend until the beginning of the next period, or until the end of the media presentation in the case of the last period. Period start times may be accurate. They may reflect the actual time resulting from playing media from all previous periods.

[0038] Cada período pode conter um ou mais representações para o mesmo conteúdo de mídia. Uma representação pode ser um de uma série de versões codificadas alternativas de dados de áudio ou de vídeo. As representações podem diferir por tipos que codificam, por exemplo, pela taxa de bits, resolução e/ou codec de dados de vídeo e taxa de bits, idioma e/ou codec para dados de áudio. A representação termo pode ser utilizada para se referir a uma secção de dados de áudio ou de vídeo codificados correspondentes a um período particular do conteúdo de multimídia e codificados de uma maneira particular.[0038] Each period may contain one or more representations for the same media content. A representation may be one of a number of alternative encoded versions of audio or video data. Representations may differ by encoding types, for example, by bitrate, resolution and/or codec for video data and bitrate, language and/or codec for audio data. The term representation may be used to refer to a section of encoded audio or video data corresponding to a particular period of multimedia content and encoded in a particular way.

[0039] As representações de um determinado período podem ser atribuídas a um grupo indicado por um atributo no MPD indicativo de uma adaptação definida a qual pertencem às representações. Representações no mesmo conjunto de adaptação são geralmente consideradas alternativas para o outro, em que um dispositivo de cliente pode dinamicamente e alternar facilmente entre essas representações, por exemplo, para realizar a adaptação da largura de banda. Por exemplo, cada representação de dados de vídeo para um determinado período pode ser atribuído ao mesmo conjunto de adaptação, de modo a que qualquer uma das representações pode ser selecionada para a decodificação de apresentar dados multimídia, tais como dados de vídeo ou de dados de áudio, do conteúdo de multimídia para o período correspondente. O teor de meios de comunicação dentro de um período pode ser representado por qualquer uma representação do grupo 0, se presente, ou a combinação de, no máximo, uma representação de cada grupo diferente de zero, em alguns exemplos. Sincronismo de dados para cada representação de um período pode ser expressa em relação ao tempo de início do período.[0039] Representations of a given period can be assigned to a group indicated by an attribute in the MPD indicative of a defined adaptation to which the representations belong. Representations in the same adaptation set are generally considered alternatives to each other, where a client device can dynamically and easily switch between these representations, for example, to perform bandwidth adaptation. For example, each video data representation for a given period can be assigned to the same adaptation set, so that any one of the representations can be selected for decoding to present multimedia data, such as video data or video data. audio, of multimedia content for the corresponding period. The media content within a period may be represented by any one representation of group 0, if present, or the combination of at most one non-zero representation of each group, in some examples. Data timing for each representation of a period can be expressed relative to the start time of the period.

[0040] A representação pode incluir um ou mais segmentos. Cada representação pode incluir um segmento de inicialização, ou cada um dos segmentos de uma representação pode ser auto-inicializar. Quando presente, o segmento de inicialização pode conter informação de inicialização para acessar a representação. Em geral, o segmento de inicialização não contém dados de mídia. Um segmento pode ser referenciado de forma única por um identificador, tal como um localizador uniforme de recursos (URL), nome uniforme de recursos (URN) ou identificador uniforme de recursos (URI). A MPD pode fornecer os identificadores para cada segmento. Em alguns exemplos, o MPD também pode proporcionar intervalos de bytes na forma de um atributo de intervalo, que podem corresponder aos dados para um segmento dentro de um arquivo acessível pelo URL, urna, ou URL.[0040] The representation may include one or more segments. Each representation may include an initialization segment, or each of the segments of a representation may be bootstrapped. When present, the initialization segment may contain initialization information for accessing the representation. In general, the boot segment does not contain media data. A segment can be uniquely referenced by an identifier, such as a uniform resource locator (URL), uniform resource name (URN), or uniform resource identifier (URI). MPD can provide the identifiers for each segment. In some examples, the MPD may also provide byte ranges in the form of a range attribute, which may correspond to data for a segment within a file accessible by URL, urn, or URL.

[0041] Diferentes representações podem ser selecionadas para a recuperação substancialmente simultânea de diferentes tipos de dados de mídia. Por exemplo, um dispositivo de cliente pode selecionar uma representação de áudio, uma representação de vídeo, e uma representação de texto cronometrado do qual recuperar segmentos. Em alguns exemplos, o dispositivo de cliente pode selecionar determinados conjuntos de adaptação para realizar a adaptação da largura de banda. Isso é o dispositivo de cliente pode selecionar um conjunto de adaptação incluindo representações de vídeo, um conjunto de adaptação incluindo representações de áudio e/ou um conjunto de adaptação incluindo texto cronometrado. Alternativamente, o dispositivo de cliente pode selecionar conjuntos de adaptação para certos tipos de mídia (por exemplo, vídeo), e selecionar diretamente representações para outros tipos de mídia (por exemplo, áudio e/ou texto cronometrado).[0041] Different representations can be selected for substantially simultaneous retrieval of different types of media data. For example, a client device may select an audio representation, a video representation, and a timed text representation from which to retrieve segments. In some examples, the client device may select certain adaptation sets to perform bandwidth adaptation. That is, the client device may select an adaptation set including video representations, an adaptation set including audio representations, and/or an adaptation set including timed text. Alternatively, the client device may select adaptation sets for certain types of media (e.g., video), and directly select representations for other types of media (e.g., audio and/or timed text).

[0042] A figura 1 é um diagrama de blocos que ilustra um exemplo de sistema 10 que implementa as técnicas desta revelação para transmissão de dados multimídia através de uma rede. vários elementos LHE de sistema 10 pode geralmente corresponder a elementos semelhantes dos exemplos mostrados nas figuras 5 e 6, como discutido em maior detalhe abaixo. Da mesma forma, os componentes do dispositivo de cliente 40 podem geralmente correspondem aos componentes das figuras 11, 12, e 14, conforme também discutido abaixo em mais detalhes.[0042] Figure 1 is a block diagram illustrating an example system 10 that implements the techniques of this disclosure for transmitting multimedia data over a network. Various LHE elements of system 10 may generally correspond to similar elements of the examples shown in Figures 5 and 6, as discussed in greater detail below. Likewise, the components of the client device 40 may generally correspond to the components of Figures 11, 12, and 14, as also discussed below in more detail.

[0043] No exemplo da figura 1, o sistema 10 inclui o dispositivo de conteúdo preparação 20, o dispositivo de servidor 60, e o dispositivo de cliente 40. dispositivo de cliente 40 e dispositivo de servidor 60 está acoplado em comunicação por rede 74, que pode compreender a Internet. Em alguns exemplos, o dispositivo de preparação de conteúdo 20 e dispositivo de servidor 60 também pode ser acoplado por rede 74 ou de outra rede, ou pode ser diretamente acoplado em comunicação. Em alguns exemplos, o conteúdo do dispositivo de preparação 20 e dispositivo de servidor 60 pode compreender o mesmo dispositivo.[0043] In the example of Figure 1, the system 10 includes the content preparation device 20, the server device 60, and the client device 40. The client device 40 and the server device 60 are coupled in network communication 74, who can understand the Internet. In some examples, the content preparation device 20 and server device 60 may also be coupled via network 74 or another network, or may be directly coupled in communication. In some examples, the contents of the preparation device 20 and server device 60 may comprise the same device.

[0044] O Dispositivo de preparação conteúdo 20, no exemplo da figura 1, compreende fonte de áudio 22 e a fonte de vídeo 24. A fonte de áudio 22 pode compreender, por exemplo, um microfone que produz sinais representativos elétricos de dados de áudio capturados a ser codificado pelo codificador de áudio 26. Em alternativa, a fonte de áudio 22 pode compreender um meio de armazenamento de armazenamento anteriormente registrados dados de áudio, um gerador de dados de áudio, como um sintetizador computadorizado, ou qualquer outra fonte de dados de áudio. fonte de vídeo 24 pode compreender uma câmara de vídeo que produz dados de vídeo a serem codificados por um codificador de vídeo 28, um meio de armazenamento codificado com dados de vídeo previamente gravados, uma unidade de geração de dados de vídeo, tal como uma fonte de gráficos de computador, ou qualquer outra fonte de dados de vídeo. Dispositivo de preparação de conteúdos 20 não é necessariamente comunicativamente acoplada ao dispositivo de servidor 60, mas pode armazenar conteúdo de multimídia para um meio separado que é lido pelo dispositivo de servidor 60.[0044] Content preparation device 20, in the example of figure 1, comprises audio source 22 and video source 24. Audio source 22 may comprise, for example, a microphone that produces electrical representative signals of audio data captured to be encoded by the audio encoder 26. Alternatively, the audio source 22 may comprise a storage medium for storing previously recorded audio data, an audio data generator such as a computerized synthesizer, or any other data source. audio. video source 24 may comprise a video camera that produces video data to be encoded by a video encoder 28, a storage medium encoded with previously recorded video data, a video data generation unit, such as a source computer graphics, or any other video data source. Content preparation device 20 is not necessarily communicatively coupled to the server device 60, but may store multimedia content to a separate medium that is read by the server device 60.

[0045] Os dados brutos de áudio e vídeo podem compreender dados analógicos ou digitais. Os dados analógicos podem ser digitalizados antes de serem codificados por codificador de áudio 26 e/ou codificador de vídeo 28. A fonte de áudio 22 pode obter dados de áudio de um participante que está falando enquanto o participante que está falando está falando, e fonte de vídeo 24 pode obter simultaneamente dados de vídeo do participante que está falando. Em outros exemplos, a fonte de áudio 22 pode compreender um meio de armazenamento de leitura por computador que compreende os dados de áudio armazenados, e a fonte de vídeo 24 pode compreender um meio de armazenamento de leitura por computador que compreende dados de vídeo armazenados. Desta forma, as técnicas descritas nesta revelação podem ser aplicadas ao fluxo contínuo, ao vivo, aos dados de áudio e vídeo em tempo real ou com dados de áudio e vídeo arquivado, pré-gravados.[0045] The raw audio and video data may comprise analog or digital data. The analog data may be digitized before being encoded by audio encoder 26 and/or video encoder 28. Audio source 22 may obtain audio data from a speaking participant while the speaking participant is speaking, and source 24 can simultaneously obtain video data from the speaking participant. In other examples, the audio source 22 may comprise a computer-readable storage medium comprising stored audio data, and the video source 24 may comprise a computer-readable storage medium comprising stored video data. In this way, the techniques described in this disclosure can be applied to streaming, live, real-time audio and video data or to archived, pre-recorded audio and video data.

[0046] Os quadros de áudio que correspondem aos quadros de vídeo são geralmente os quadros de áudio contendo dados de áudio que foram capturados (ou gerados) com fonte de áudio 22 contemporaneamente com dados de vídeo capturado (ou gerados) pela fonte de vídeo 24 que está contida dentro dos quadros de vídeo. Por exemplo, enquanto um participante falando geralmente produz dados de áudio, falando, fonte de áudio 22 capta os dados de áudio e fonte de vídeo 24 captura os dados de vídeo do participante que está falando ao mesmo tempo, isto é, enquanto fonte de áudio 22 é capturar os dados de áudio. Assim, uma trama de áudio podem temporalmente correspondem a um ou mais quadros de vídeo particulares. Deste modo, um quadro de áudio correspondente a um quadro de vídeo geralmente corresponde a uma situação em que os dados de dados e de áudio e vídeo foram capturadas ao mesmo tempo e para que um quadro de áudio e um quadro de vídeo compreendem, respectivamente, os dados de áudio e os dados de vídeo que foi capturado ao mesmo tempo.[0046] The audio frames that correspond to the video frames are generally the audio frames containing audio data that were captured (or generated) with audio source 22 contemporaneously with video data captured (or generated) by the video source 24 that is contained within the video frames. For example, while a participant speaking generally produces audio data, speaking, audio source 22 captures the audio data and video source 24 captures the video data of the participant speaking at the same time, i.e., while the audio source 22 is to capture the audio data. Thus, an audio frame may temporally correspond to one or more particular video frames. Thus, an audio frame corresponding to a video frame generally corresponds to a situation in which data and audio and video data were captured at the same time and for which an audio frame and a video frame respectively comprise the audio data and the video data that was captured at the same time.

[0047] Em alguns exemplos, o codificador de áudio 26 pode codificar um marcador de tempo em cada trama de áudio codificado que representa um tempo em que os dados de áudio para o quadro de áudio codificado foi registrado, e de forma semelhante, um codificador de vídeo 28 pode codificar um marcador de tempo em cada vídeo codificado quadro que representa um tempo no qual os dados de vídeo para quadro de vídeo codificado foi gravado. Em tais exemplos, um quadro de áudio correspondente a um quadro de vídeo pode compreender um quadro de áudio, compreendendo um marcador de tempo e um quadro de vídeo que compreende a mesma hora. O dispositivo de preparação de conteúdo 20 pode incluir um relógio interno a partir do qual codificador de áudio 26 e/ou codificador de vídeo 28 pode gerar as marcas de tempo, ou que fonte de fonte de áudio e de vídeo 22, 24 podem utilizar para associar os dados de áudio e de vídeo, respectivamente, com um carimbo de hora.[0047] In some examples, the audio encoder 26 may encode a time marker in each encoded audio frame that represents a time at which the audio data for the encoded audio frame was recorded, and similarly, an encoder video frame 28 may encode a time marker in each encoded video frame that represents a time at which the video data for the encoded video frame was recorded. In such examples, an audio frame corresponding to a video frame may comprise an audio frame comprising a timestamp and a video frame comprising the same time. Content preparation device 20 may include an internal clock from which audio encoder 26 and/or video encoder 28 may generate timestamps, or which audio and video source 22, 24 may use to associate audio and video data, respectively, with a time stamp.

[0048] Em alguns exemplos, a fonte de áudio 22 pode enviar dados para o codificador de áudio 26, correspondendo a um tempo em que os dados de áudio foram registrados, e a fonte de vídeo 24 pode enviar dados para o codificador de vídeo 28, que corresponde a um tempo no qual os dados de vídeo foram gravados. Em alguns exemplos, o codificador de áudio 26 podem codificar um identificador de sequência em dados de áudio codificados para indicar uma ordenação temporal relativa de dados de áudio codificados, mas sem indicando necessariamente um tempo absoluto no qual os dados de áudio foram registrados, e de forma semelhante, um codificador de vídeo 28 também pode utilizar identificadores de seqüência para indicar uma ordenação temporal relativa de dados de vídeo codificados. Do mesmo modo, em alguns exemplos, um identificador de sequência pode ser mapeado ou de outra forma correlacionados com um marcador de tempo.[0048] In some examples, the audio source 22 may send data to the audio encoder 26 corresponding to a time at which the audio data was recorded, and the video source 24 may send data to the video encoder 28 , which corresponds to a time at which the video data was recorded. In some examples, the audio encoder 26 may encode a sequence identifier in encoded audio data to indicate a relative temporal ordering of encoded audio data, but without necessarily indicating an absolute time at which the audio data was recorded, and Similarly, a video encoder 28 may also use sequence identifiers to indicate a relative temporal ordering of encoded video data. Likewise, in some examples, a sequence identifier may be mapped or otherwise correlated with a timestamp.

[0049] Codificador de áudio 26 geralmente produz um fluxo de dados de áudio codificados, enquanto codificador de vídeo 28 produz uma corrente de dados de vídeo codificados. Cada fluxo individual de dados (seja de áudio ou vídeo) pode ser referido como um fluxo elementar. Um fluxo elementar é um componente único digitalmente codificado, (possivelmente comprimido) de uma representação. Por exemplo, o vídeo codificado ou parte de áudio da representação pode ser um fluxo elementar. Um fluxo elementar pode ser convertido em um fluxo elementar em pacotes (PES) antes de ser encapsulado dentro de um arquivo de vídeo. Dentro da mesma representação, o ID do fluxo pode ser utilizado para distinguir aos pacotes PES pertencentes a um fluxo elementar a partir do outro. A unidade de base de dados de um fluxo elementar em pacotes é um pacote de fluxo elementar (PES). Assim, os dados de vídeo codificados geralmente correspondem aos fluxos de vídeo elementares. Da mesma forma, os dados de áudio correspondem a um ou mais respectivos fluxos elementares.[0049] Audio encoder 26 generally produces a stream of encoded audio data, while video encoder 28 produces a stream of encoded video data. Each individual stream of data (whether audio or video) can be referred to as an elementary stream. An elementary stream is a single digitally encoded, (possibly compressed) component of a representation. For example, the encoded video or audio portion of the representation may be an elementary stream. An elementary stream can be converted to a packetized elementary stream (PES) before being encapsulated within a video file. Within the same representation, the flow ID can be used to distinguish PES packets belonging to one elementary flow from another. The database unit of a packetized elementary flow is an elementary flow packet (PES). Thus, encoded video data generally corresponds to elementary video streams. Likewise, audio data corresponds to one or more respective elementary streams.

[0050] Muitos padrões de codificação de vídeo, tais como ITU-T H.264/AVC e o padrão de código de vídeo de alta eficiência (HEVC) vindouro, definem a sintaxe, semântica e processo de decodificação de fluxos de bits sem erros, qualquer um que cumpra um determinado perfil ou nível. As normas de codificação de vídeo geralmente não especificam o codificador, mas o codificador tem a tarefa de garantir que os fluxos de bits gerados são padrão compatível para um decodificador. No contexto do vídeo padrões de codificação, um “perfil” corresponde a um subconjunto de algoritmos, recursos ou ferramentas e restrições que lhes são aplicáveis. Tal como definido pela norma H.264, por exemplo, um “perfil” é um subconjunto de toda a sintaxe de fluxo de bits que é especificada pela norma H.264. Um “nível” corresponde às limitações do consumo de recursos do decodificador, tais como, por exemplo, de memória do decodificador e cálculo, que estão relacionados com a resolução das imagens, a taxa de bits, e taxa de processamento do bloco. Um perfil pode ser sinalizado com um valor do perfil idc (indicador de perfil), ao passo que um nível pode ser sinalizado com um valor nível_idc (indicador de nível).[0050] Many video coding standards, such as ITU-T H.264/AVC and the upcoming High Efficiency Video Code (HEVC) standard, define the syntax, semantics, and decoding process of error-free bit streams , anyone who meets a certain profile or level. Video coding standards generally do not specify the encoder, but the encoder is tasked with ensuring that the generated bit streams are standard compatible for a decoder. In the context of video coding standards, a “profile” corresponds to a subset of algorithms, resources or tools and constraints that apply to them. As defined by the H.264 standard, for example, a “profile” is a subset of the entire bitstream syntax that is specified by the H.264 standard. A “level” corresponds to the limitations of decoder resource consumption, such as, for example, decoder memory and calculation, which are related to image resolution, bit rate, and block processing rate. A profile can be flagged with a profile idc (profile indicator) value, whereas a level can be flagged with a level_idc (level indicator) value.

[0051] A norma H.264, por exemplo, reconhece que, dentro dos limites impostos pela sintaxe de um determinado perfil, ainda é possível requerer uma grande variação no desempenho de codificadores e decodificadores dependendo dos valores tomados pela sintaxe elementos no fluxo de bits como o tamanho especificado das imagens decodificadas. O padrão H.264 reconhece ainda que, em muitas aplicações, não é nem prático nem econômico para implementar um decodificador capaz de lidar com todos os usos hipotéticos da sintaxe dentro de um perfil particular. Por conseguinte, o padrão H.264 define um “nível”, como um conjunto específico de restrições impostas sobre os valores dos elementos de sintaxe no fluxo de bits. Estas restrições podem ser simples limites em valores. Alternativamente, estas restrições podem tomar a forma de constrangimentos sobre combinações aritméticas de valores (por exemplo, largura de imagem multiplicada pela altura de imagem multiplicada pelo número de imagens decodificadas por segundo). A norma H.264 fornece, ainda, que as implementações individuais podem suportar um nível diferente para cada perfil de suporte.[0051] The H.264 standard, for example, recognizes that, within the limits imposed by the syntax of a given profile, it is still possible to require a large variation in the performance of encoders and decoders depending on the values taken by the syntax elements in the bit stream. as the specified size of the decoded images. The H.264 standard further recognizes that, in many applications, it is neither practical nor economical to implement a decoder capable of handling all hypothetical uses of the syntax within a particular profile. Therefore, the H.264 standard defines a “level” as a specific set of restrictions imposed on the values of syntax elements in the bitstream. These restrictions can be simple limits on values. Alternatively, these restrictions may take the form of constraints on arithmetic combinations of values (e.g., image width multiplied by image height multiplied by the number of images decoded per second). The H.264 standard further provides that individual implementations can support a different level for each support profile.

[0052] Um decodificador em conformidade com um perfil normalmente suporta todas as características definidas no perfil. Por exemplo, como uma característica de codificação, codificação de imagem B não é suportada no perfil de base do H.264/AVC, mas é suportada em outros perfis de H.264/AVC. Um decodificador em conformidade com um nível deve ser capaz de decodificar qualquer fluxo de bits que não requer recursos além dos limites definidos no nível. Definições de perfis e níveis podem ser úteis para a interoperabilidade. Por exemplo, durante a transmissão de vídeo, um par de definições de perfis e de nível pode ser negociado e acordado para uma sessão de transmissão de todo. Mais especificamente, em H.264/AVC, um nível pode definir limitações sobre o número de macroblocos que precisam ser processados, o tamanho do buffer de imagem decodificada (DPB) tamanho, armazenamento imagem codificada (CEC), faixa de vetor de movimento vertical, o número máximo de vetores de movimento por dois MBs consecutivos, e se um bloco B pode ter partições de sub - macrobloco inferiores a 8x8 pixels. Desta maneira, um decodificador pode determinar se o decodificador é capaz de decodificar corretamente o fluxo de bits.[0052] A decoder conforming to a profile typically supports all characteristics defined in the profile. For example, as an encoding feature, B image encoding is not supported in the H.264/AVC base profile, but is supported in other H.264/AVC profiles. A decoder conforming to a level must be able to decode any bit stream that does not require resources beyond the limits defined in the level. Profiling and level definitions can be useful for interoperability. For example, during video streaming, a couple of profile and level settings can be negotiated and agreed upon for an entire streaming session. More specifically, in H.264/AVC, a level can set limitations on the number of macroblocks that need to be processed, decoded image buffer (DPB) size, encoded image storage (CEC), vertical motion vector range , the maximum number of motion vectors for two consecutive MBs, and whether a B block can have submacroblock partitions smaller than 8x8 pixels. In this way, a decoder can determine whether the decoder is capable of correctly decoding the bit stream.

[0053] No exemplo da figura 1, a unidade de encapsulação 30 do dispositivo de preparação de conteúdo 20 recebe fluxos elementares que compreendem dados de vídeo codificados a partir de um codificador de vídeo 28 e os fluxos elementares de áudio que compreendem dados codificados do codificador de áudio 26. Em alguns exemplos, o codificador de vídeo 28 e um codificador de áudio 26 podem cada um incluir empacotadores para formar pacotes PES de dados codificados. Em outros exemplos, o codificador de vídeo 28 e um codificador de áudio 26 podem cada interface com respectivos empacotadores para formar pacotes PES de dados codificados. Em ainda outros exemplos, a unidade de encapsulação 30 pode incluir empacotadores para formar pacotes codificados PES de dados de áudio e de vídeo.[0053] In the example of Figure 1, the encapsulation unit 30 of the content preparation device 20 receives elementary streams comprising encoded video data from a video encoder 28 and elementary audio streams comprising encoded data from the encoder audio encoder 26. In some examples, the video encoder 28 and an audio encoder 26 may each include packetizers to form PES packets of encoded data. In other examples, the video encoder 28 and an audio encoder 26 may each interface with respective packetizers to form PES encoded data packets. In still other examples, the encapsulation unit 30 may include packetizers to form PES-encoded packets of audio and video data.

[0054] O codificador de vídeo 28 pode codificar dados de vídeo de conteúdo de multimídia em uma variedade de maneiras, para produzir diferentes representações do conteúdo de multimídia em várias taxas de bits e com várias características, tais como pixels de resolução, taxas de quadros, a conformidade com vários padrões de codificação, conformidade a vários perfis e/ou níveis de perfis para vários padrões de codificação, representações ter um ou vários pontos de vista (por exemplo, para bidimensional ou tridimensional de reprodução), ou outros tais características. Uma representação, tal como utilizado na presente memória descritiva, pode compreender uma de dados de áudio, dados de vídeo, dados de texto (por exemplo, para as legendas fechadas), ou outros dados semelhantes. A representação pode incluir um fluxo elementar, tal como um fluxo elementar de áudio ou de um fluxo elementar de vídeo. Cada pacote PES pode incluir um ID de fluxo que identifica o fluxo elementar ao qual pertence o pacote PES. A unidade de encapsulação 30 é responsável pela montagem fluxos elementares em arquivos de vídeo (por exemplo, segmentos) de várias representações.[0054] The video encoder 28 can encode video data of multimedia content in a variety of ways, to produce different representations of the multimedia content at various bit rates and with various characteristics, such as resolution pixels, frame rates , conformance to multiple encoding standards, compliance to multiple profiles and/or levels of profiles for multiple encoding standards, representations having one or multiple views (e.g., for two-dimensional or three-dimensional playback), or other such characteristics. A representation, as used herein, may comprise one of audio data, video data, text data (e.g., for closed captions), or other similar data. The representation may include an elementary stream, such as an audio elementary stream or an elementary video stream. Each PES packet may include a stream ID that identifies the elementary stream to which the PES packet belongs. The encapsulation unit 30 is responsible for assembling elementary streams into video files (e.g., segments) of various representations.

[0055] A unidade de encapsulação 30 recebe pacotes PES para os fluxos elementares de uma representação do codificador de áudio 26 e o codificador de vídeo 28 e forma as unidades de camada de abstração de rede correspondente (NAL) a partir dos pacotes PES. No exemplo de H.264/AVC (Código de vídeo Avançado), segmentos de vídeo codificados são organizados em unidades NAL, que fornecem uma representação de vídeo “amigável para a rede” abordando aplicações como vídeo telefonia, armazenamento, difusão ou fluxo contínuo. As unidades NAL podem ser categorizadas como unidades de camada de código de vídeo (VCL) NAL unidades e unidades NAL não-VCL. As unidades VCL podem conter o motor de compactação do núcleo e pode incluir bloco, macro bloco, e/ou dados de nível de fatia. Outras unidades NAL podem ser unidades NAL não-VCL. Em alguns exemplos, uma imagem codificada em um instante de tempo, normalmente apresentada como uma imagem primária codificada pode estar contida em uma unidade de acesso, que pode incluir uma ou mais unidades NAL.[0055] The encapsulation unit 30 receives PES packets for the elementary streams of a representation of the audio encoder 26 and the video encoder 28 and forms the corresponding network abstraction layer (NAL) units from the PES packets. In the example of H.264/AVC (Advanced Video Code), encoded video segments are organized into NAL units, which provide a “network-friendly” video representation addressing applications such as video telephony, storage, broadcast, or streaming. NAL units can be categorized as video code layer (VCL) NAL units and non-VCL NAL units. VCL units may contain the core compression engine and may include block, macro block, and/or slice level data. Other NAL units may be non-VCL NAL units. In some examples, an image encoded at an instant of time, typically presented as a primary encoded image, may be contained in an access unit, which may include one or more NAL units.

[0056] As unidades NAL não-VCL podem incluir unidades NAL de parâmetro definido e unidades SEI NAL, entre outros. Os conjuntos de parâmetros podem conter informações de cabeçalho de nível de sequência (em conjuntos de sequências de parâmetros (SPS)) e a informação de cabeçalho raramente mudar de nível de imagem (em conjuntos de parâmetros de imagem (PPS)). Com os conjuntos de parâmetros (por exemplo, PPS e SPS), raramente mudar a informação não necessita de ser repetido para cada sequência ou imagem, por conseguinte, a eficiência de codificação pode ser melhorada. Além disso, o uso de conjuntos de parâmetros pode permitir a transmissão fora de faixa da informação importante cabeçalho, evitando a necessidade de transmissões redundantes para a resiliência erro. Em exemplos de transmissão fora de faixa, unidades NAL de parâmetro definido podem ser transmitidas num canal diferente do que outras unidades NAL, tais como unidades NAL SEI.[0056] Non-VCL NAL units may include parameter-defined NAL units and SEI NAL units, among others. Parameter sets can contain sequence-level header information (in parameter sequence sets (SPS)) and the header information rarely changes image level (in image parameter sets (PPS)). With parameter sets (e.g. PPS and SPS), rarely changing information does not need to be repeated for each sequence or image, therefore coding efficiency can be improved. Additionally, the use of parameter sets can allow out-of-band transmission of important header information, avoiding the need for redundant transmissions for error resiliency. In examples of out-of-band transmission, parameter-defined NAL units may be transmitted on a different channel than other NAL units, such as SEI NAL units.

[0057] Suplementar de Enriquecimento de Informação (SEI) pode conter informações que não é necessário para decodificar as imagens de amostras codificadas de unidades VCL Nal, mas pode ajudar em processos relacionados com a decodificação, exibição, resiliência de erro, e outros fins. As mensagens SEI podem estar contidas em unidades não-VCL NAL. As mensagens SEI são a parte normativa de algumas especificações padrão e, portanto, nem sempre são obrigatórios para a implementação decodificador compatível padrão. As mensagens SEI podem ser mensagens SEI nível seqüência ou mensagens SEI nível de imagem. Algumas informações nível da sequência podem estar contidos nas mensagens SEI, tais como mensagens de informações escalabilidade SEI no exemplo de CVL e vista escalabilidade informação mensagens SEI no MVC. Esses exemplos de mensagens SEI podem transmitir informações sobre, por exemplo, extração de pontos de operação e características dos pontos de operação. Além disso, a unidade de encapsulação 30 pode formar um arquivo de manifesto, tal como um descritor de apresentação de mídia (MPD) que descreve as características das representações. A unidade de encapsulação 30 pode formatar o MPD de acordo com a linguagem de marcação extensível (XML).[0057] Supplemental Enrichment Information (SEI) may contain information that is not necessary to decode the encoded sample images of Nal VCL units, but may assist in processes related to decoding, display, error resilience, and other purposes. SEI messages may be contained in non-VCL NAL units. SEI messages are the normative part of some standard specifications and therefore are not always mandatory for standard compatible decoder implementation. SEI messages can be sequence level SEI messages or image level SEI messages. Some sequence level information may be contained in SEI messages, such as SEI scalability information messages in the CVL example and SEI view scalability information messages in MVC. These example SEI messages can convey information about, for example, operating point extraction and operating point characteristics. Furthermore, the encapsulation unit 30 may form a manifest file, such as a media presentation descriptor (MPD) that describes the characteristics of the representations. The encapsulation unit 30 can format the MPD according to extensible markup language (XML).

[0058] A unidade de encapsulação 30 pode fornecer dados para um ou mais representações de conteúdo de multimídia, juntamente com o arquivo de manifesto de (por exemplo, o MPD) de interface de saída 32. Interface de saída 32 pode compreender uma interface de rede ou uma interface para escrever para um armazenamento meio, como uma interface de barramento serial universal (USB), um CD ou DVD ou gravador, uma interface para mídias magnéticas ou flash, ou outras interfaces para armazenar ou transmitir dados de mídia. A unidade de encapsulação 30 pode fornecer dados de cada uma das representações de conteúdo de multimídia a interface de saída 32, que podem enviar os dados para o dispositivo de servidor 60 através de transmissão de rede ou mídia de armazenamento. No exemplo da figura 1, o dispositivo de servidor 60 inclui o meio de armazenamento 62, que armazena vários conteúdos multimídia 64, cada um incluindo um respectivo arquivo de manifesto de 66 e uma ou mais representações 68A-68N (representações 68). Em alguns exemplos, a interface de saída 32 também pode enviar os dados diretamente para a rede 74.[0058] The encapsulation unit 30 may provide data for one or more multimedia content representations, together with the manifest file (e.g., the MPD) of output interface 32. Output interface 32 may comprise a network or an interface for writing to a storage medium, such as a universal serial bus (USB) interface, a CD or DVD recorder, an interface for magnetic or flash media, or other interfaces for storing or transmitting media data. The encapsulation unit 30 may provide data from each of the multimedia content representations to the output interface 32, which may send the data to the server device 60 via network transmission or storage media. In the example of Figure 1, the server device 60 includes the storage medium 62, which stores various multimedia contents 64, each including a respective manifest file 66 and one or more representations 68A-68N (representations 68). In some examples, the output interface 32 may also send data directly to the network 74.

[0059] Em alguns exemplos, as representações 68 podem ser separadas em conjuntos de adaptação. Ou seja, vários subconjuntos de representações 68 podem incluir respectivos conjuntos comuns de características, como codec, perfil e nível, resolução, número de visualizações, formato de arquivo para segmentos, digite o texto de informações que podem identificar um idioma ou outras características de texto a ser exibido com os dados de áudio representação e/ou para ser decodificados e apresentados, por exemplo, por alto-falantes, câmera ângulo informações que podem descrever um ângulo de câmera ou do mundo real perspectiva da câmera de uma cena para representações no conjunto de adaptação, informações a classificação que descreve o conteúdo adequação para públicos específicos, ou similares.[0059] In some examples, representations 68 can be separated into adaptation sets. That is, various subsets of representations 68 may include respective common sets of characteristics, such as codec, profile and level, resolution, number of views, file format for segments, type information text that can identify a language, or other text characteristics. to be displayed with the audio representation data and/or to be decoded and presented, for example, by speakers, camera angle information that may describe a camera angle or real-world camera perspective of a scene for representations in the set adaptation, classification information that describes content suitability for specific audiences, or similar.

[0060] O arquivo de manifesto 66 pode incluir dados indicativos dos subconjuntos de representações 68 correspondentes a conjuntos específicos de adaptação, bem como características comuns para os conjuntos de adaptação. O arquivo de manifesto 66 também pode incluir dados representativos de características individuais, tais como taxas de bits, por representações individuais de conjuntos de adaptação. Desta forma, um conjunto de adaptação pode prever uma adaptação da largura de banda de rede simplificada. Representações em um conjunto de adaptação podem ser indicadas através de elementos filho de um elemento de adaptação do conjunto arquivo de manifesto 66.[0060] Manifest file 66 may include data indicative of the subsets of representations 68 corresponding to specific adaptation sets, as well as common characteristics for the adaptation sets. The manifest file 66 may also include data representing individual characteristics, such as bit rates, for individual adaptation set representations. In this way, an adaptation set can provide for simplified network bandwidth adaptation. Representations in an adaptation set may be indicated through child elements of an adaptation element of the manifest file set 66.

[0061] O dispositivo de servidor 60 inclui unidade de processamento de solicitação 70 e a interface de rede 72. Em alguns exemplos, o dispositivo de servidor 60 pode incluir uma pluralidade de interfaces de rede. Além disso, qualquer uma ou todas as características do dispositivo de servidor 60 podem ser implementados em outros dispositivos de uma rede de distribuição de conteúdos, tais como encaminhadores, pontes, dispositivos de proxy, interruptores, ou outros dispositivos. Em alguns exemplos, os dispositivos intermédios de uma rede de distribuição de conteúdo podem armazenar em cache de dados de conteúdos multimídia 64, e incluem componentes que substancialmente em conformidade com aqueles do dispositivo de servidor 60. De um modo geral, de interface de rede 72 é configurado para enviar e receber dados através da rede 74.[0061] The server device 60 includes request processing unit 70 and the network interface 72. In some examples, the server device 60 may include a plurality of network interfaces. Furthermore, any or all of the features of the server device 60 may be implemented in other devices of a content delivery network, such as routers, bridges, proxy devices, switches, or other devices. In some examples, intermediate devices of a content delivery network may cache multimedia content data 64, and include components that substantially conform to those of server device 60. Generally speaking, network interface 72 is configured to send and receive data over network 74.

[0062] A unidade de processamento de solicitação 70 é configurada para receber pedidos de rede de dispositivos de cliente, tais como dispositivo de cliente 40, para os dados do meio de armazenamento 62. Por exemplo, a unidade de processamento de solicitação 70 pode implementar o protocolo de transferência de hipertexto (HTTP) versão 1.1, como descrito no RFC 2616, “Hypertext Transfer Protocol - HTTP/1.1,” por R. Fielding e outros, Grupo de Trabalho de Rede, IETF, de junho de 1999. Ou seja, unidade de processamento de solicitação 70 pode ser configurada para receber HTTP GET ou solicitações GET parciais e fornecer dados de conteúdos multimídia 64 em resposta às solicitações. As solicitações podem especificar um segmento de uma das representações 68, por exemplo, usando uma URL do segmento. Em alguns exemplos, os pedidos também podem especificar um ou mais intervalos de bytes do segmento, compreendendo, assim, pedidos GET parciais. A unidade de processamento de solicitação 70 pode ainda ser configurada para pedidos HTTP HEAD de serviço para fornecer dados de cabeçalho de um segmento de uma das representações 68. Em qualquer caso, a unidade de processamento de solicitação 70 pode ser configurada para processar os pedidos para fornecer os dados solicitados para um dispositivo solicitador, tal como o dispositivo de cliente 40.[0062] Request processing unit 70 is configured to receive network requests from client devices, such as client device 40, for data from storage medium 62. For example, request processing unit 70 may implement the Hypertext Transfer Protocol (HTTP) version 1.1, as described in RFC 2616, “Hypertext Transfer Protocol - HTTP/1.1,” by R. Fielding et al., Network Working Group, IETF, June 1999. That is , request processing unit 70 may be configured to receive HTTP GET or partial GET requests and provide multimedia content data 64 in response to the requests. Requests may specify a segment from one of the 68 representations, for example, using a segment URL. In some examples, requests may also specify one or more segment byte ranges, thus comprising partial GET requests. The request processing unit 70 may further be configured to service HTTP HEAD requests to provide header data from a segment of one of the representations 68. In any case, the request processing unit 70 may be configured to process the requests for providing the requested data to a requesting device, such as client device 40.

[0063] Adicionalmente, ou alternativamente, a unidade de processamento de solicitação 70 pode ser configurada para fornecer dados de multimídia através de protocolo difusão ou multidifusão, tal como eMBMS. O dispositivo de preparação de conteúdo 20 pode criar segmentos DASH e/ou segmentos secundários substancialmente da mesma maneira como descrito, mas o dispositivo de servidor 60 pode fornecer estes segmentos ou segmentos secundários usando eMBMS ou outro protocolo de transporte de rede de difusão ou multidifusão. Por exemplo, a unidade de processamento de solicitação 70 pode ser configurada para receber uma solicitação de associação a grupo de multidifusão a partir do dispositivo de cliente 40. Isto é, dispositivo de servidor 60 pode anunciar um endereço de Protocolo da Internet (IP) associado a um grupo de multidifusão para dispositivos de clientes, incluindo dispositivo de cliente 40, associado com particular conteúdo de mídia (por exemplo, uma transmissão de um evento ao vivo). O dispositivo de cliente 40, por sua vez, pode apresentar um pedido para se juntar ao grupo de multidifusão. Esse pedido pode ser propagado em toda a rede 74, por exemplo, os roteadores que compõem rede 74, de tal forma que os roteadores são causados para direcionar o tráfego destinado para o endereço IP associado ao grupo de multidifusão para dispositivos clientes que subscrevam, tais como dispositivo de cliente 40.[0063] Additionally, or alternatively, request processing unit 70 may be configured to provide multimedia data via broadcast or multicast protocol, such as eMBMS. The content preparation device 20 may create DASH segments and/or secondary segments in substantially the same manner as described, but the server device 60 may provide these segments or secondary segments using eMBMS or another broadcast or multicast network transport protocol. For example, request processing unit 70 may be configured to receive a multicast group membership request from client device 40. That is, server device 60 may advertise an associated Internet Protocol (IP) address. to a multicast group for client devices, including client device 40, associated with particular media content (e.g., a broadcast of a live event). The client device 40, in turn, may submit a request to join the multicast group. This request may be propagated throughout network 74, e.g., the routers that make up network 74, such that the routers are caused to direct traffic destined for the IP address associated with the multicast group to client devices that subscribe, such as client device 40.

[0064] Tal como ilustrado no exemplo da figura 1, teor de multimídia 64 inclui arquivo de manifesto de 66, que pode corresponder a uma descrição apresentação de mídia (MPD). O arquivo de manifesto 66 pode conter descrições de alternativas diferentes representações 68 (por exemplo, serviços de vídeo com diferentes qualidades) e a descrição pode incluir, por exemplo, informações codec, um valor de perfil, um valor de nível, uma taxa de bits, e outras características descritivas das representações 68. O dispositivo de cliente 40 pode recuperar o MPD de uma apresentação de mídia para determinar como acessar segmentos de representações 68.[0064] As illustrated in the example of Figure 1, multimedia content 64 includes manifest file 66, which may correspond to a media presentation description (MPD). The manifest file 66 may contain descriptions of different alternative representations 68 (e.g., video services with different qualities) and the description may include, for example, codec information, a profile value, a level value, a bitrate. , and other descriptive characteristics of representations 68. Client device 40 may retrieve the MPD of a media presentation to determine how to access segments of representations 68.

[0065] Em particular, a unidade de recuperação de 52 pode recuperar dados de configuração (não mostrado) do dispositivo de cliente 40 para determinar as capacidades de decodificação de vídeo decodificador 48 e capacidades de renderização de saída de vídeo 44. Os dados de configuração também podem incluir qualquer um ou todos de uma preferência de idioma selecionado por um usuário do dispositivo de cliente 40, um ou mais perspectivas câmara correspondente às preferências de profundidade definidos pelo usuário do dispositivo de cliente 40, e/ou uma classificação de preferência selecionada pelo usuário do dispositivo de cliente 40. A unidade de recuperação 52 pode compreender, por exemplo, um navegador web ou um cliente de mídia configurado para enviar solicitações HTTP GET e GET parcial. A unidade de recuperação 52 pode corresponder com as instruções de software executadas por um ou mais processadores ou unidades de processamento (não mostrados) do dispositivo de cliente 40. Em alguns exemplos, todas ou partes da funcionalidade descrita com respeito à unidade de recuperação de 52 podem ser implementadas em hardware, ou uma combinação de hardware, software e/ou firmware, hardware, onde requerida pode ser proporcionada para executar instruções para o software ou firmware.[0065] In particular, the retrieval unit 52 may retrieve configuration data (not shown) from the client device 40 to determine the video decoding capabilities of decoder 48 and video output rendering capabilities 44. The configuration data may also include any or all of a language preference selected by a user of the client device 40, one or more camera perspectives corresponding to depth preferences defined by the user of the client device 40, and/or a preference rating selected by the user of the client device 40. The recovery unit 52 may comprise, for example, a web browser or a media client configured to send HTTP GET and partial GET requests. Recovery unit 52 may correspond to software instructions executed by one or more processors or processing units (not shown) of client device 40. In some examples, all or parts of the functionality described with respect to recovery unit 52 may be implemented in hardware, or a combination of hardware, software and/or firmware, where required hardware may be provided to execute instructions for the software or firmware.

[0066] Unidade de recuperação 52 pode comparar as capacidades de decodificação e de renderização do dispositivo de cliente 40 para características de representações 68 indicadas por informação de arquivo de manifesto 66. A unidade de recuperação 52 pode, inicialmente, recuperar, pelo menos, uma porção de arquivo de manifesto de 66 para determinar as características de representações 68. Por exemplo, a unidade de recuperação de 52 pode solicitar uma porção de arquivo de manifesto 66 que descreve as características de um ou mais conjuntos de adaptação. A unidade de recuperação 52 pode selecionar um subconjunto de representações 68 (por exemplo, um conjunto de adaptação) que têm características que podem ser satisfeitas pela codificação e capacidades de render dispositivo de cliente 40. Unidade de recuperação 52 pode, então, determinar as taxas de bits para representações no conjunto de adaptação, determinar uma quantidade atualmente disponível de largura de banda de rede, e recuperar segmentos de uma das representações que têm uma taxa de bits que pode ser satisfeito pela largura de banda de rede.[0066] Retrieval unit 52 may compare the decoding and rendering capabilities of client device 40 to characteristics of representations 68 indicated by manifest file information 66. Retrieval unit 52 may initially retrieve at least one manifest file portion 66 to determine characteristics of representations 68. For example, recovery unit 52 may request a manifest file portion 66 that describes characteristics of one or more adaptation sets. The retrieval unit 52 may select a subset of representations 68 (e.g., an adaptation set) that have characteristics that can be satisfied by the encoding and rendering capabilities of client device 40. Retrieval unit 52 may then determine the rates of bits for representations in the adaptation set, determine a currently available amount of network bandwidth, and retrieve segments from one of the representations that have a bit rate that can be satisfied by the network bandwidth.

[0067] Em geral, as representações de taxa de bits mais elevadas podem produzir a reprodução de vídeo de qualidade superior, enquanto as representações de taxa de bits mais baixas podem proporcionar a reprodução de vídeo de qualidade suficiente quando diminui a largura de banda disponível da rede. Por conseguinte, quando a largura de banda disponível da rede é relativamente elevada, a unidade de recuperação de 52 pode recuperar os dados a partir de representações relativamente elevados de taxa de bits, ao passo que quando a largura de banda disponível da rede é baixa, a unidade de recuperação de 52 pode recuperar os dados a partir de representações relativamente baixa de taxa de bits. Desta forma, o dispositivo de cliente 40 pode transmitir dados multimídia através da rede 74 ao mesmo tempo em que se adaptar às mudanças disponibilidade de largura de banda da rede 74.[0067] In general, higher bitrate representations can produce higher quality video playback, while lower bitrate representations can provide sufficient quality video playback when the available bandwidth of the network. Therefore, when the available network bandwidth is relatively high, the recovery unit 52 can recover data from relatively high bitrate representations, whereas when the available network bandwidth is low, The recovery unit 52 can recover data from relatively low bitrate representations. In this way, client device 40 can transmit multimedia data over network 74 while adapting to changing bandwidth availability of network 74.

[0068] Adicionalmente ou alternativamente, a unidade de recuperação de 52 pode ser configurado para receber dados de acordo com um protocolo de rede de difusão ou multidifusão, tal como eMBMS ou multidifusão IP. Em tais exemplos, a unidade de recuperação de 52 pode apresentar um pedido para se juntar a um grupo de rede de multidifusão associado com conteúdo de mídia específica. Depois de entrar para o grupo de multidifusão, a unidade de recuperação de 52 pode receber dados do grupo de multidifusão sem mais pedidos emitidos para o dispositivo de servidor 60 ou dispositivo de preparação de conteúdos 20. A unidade de recuperação 52 pode apresentar um pedido para deixar o grupo de multidifusão quando os dados do grupo de multidifusão não forem mais necessários, por exemplo, para interromper a reprodução ou para mudar de canal a um grupo de multidifusão diferente.[0068] Additionally or alternatively, the recovery unit 52 may be configured to receive data in accordance with a broadcast or multicast network protocol, such as eMBMS or IP multicast. In such examples, the retrieval unit 52 may submit a request to join a multicast network group associated with specific media content. After joining the multicast group, the recovery unit 52 may receive data from the multicast group without further requests being issued to the server device 60 or content preparation device 20. The recovery unit 52 may submit a request to leave the multicast group when the multicast group data is no longer needed, for example, to stop playback or to change channels to a different multicast group.

[0069] A interface de rede 54 pode receber e fornecer dados de segmentos de uma representação selecionada para unidade de recuperação 52, que por sua vez pode proporcionar os segmentos para a unidade de encapsulação inversa 50. Unidade de encapsulação inversa 50 pode encapsular inversamente os elementos de um arquivo de vídeo em fluxos PES constituintes, desempacotar fluxos PES para recuperar os dados codificados, e enviar os dados codificados para qualquer decodificador de áudio 46 ou decodificador de vídeo 48, dependendo se os dados codificados é parte de um fluxo de áudio ou vídeo, por exemplo, como indicado por Cabeçalhos de pacotes PES do fluxo. O decodificador de áudio 46 decodifica os dados de áudio codificados e envia os dados de áudio decodificados de saída de áudio 42, enquanto decodificador de vídeo 48 decodifica dados codificados de vídeo e envia os dados de vídeo decodificados, que podem incluir uma pluralidade de pontos de vista de uma corrente, a saída de vídeo 44.[0069] Network interface 54 can receive and provide segment data of a selected representation to recovery unit 52, which in turn can provide the segments to the reverse encapsulation unit 50. Reverse encapsulation unit 50 can reverse encapsulate the elements of a video file into constituent PES streams, unpack PES streams to recover the encoded data, and send the encoded data to either audio decoder 46 or video decoder 48, depending on whether the encoded data is part of an audio stream or video, for example, as indicated by Stream PES Packet Headers. Audio decoder 46 decodes the encoded audio data and outputs the decoded audio data to audio output 42, while video decoder 48 decodes encoded video data and outputs the decoded video data, which may include a plurality of audio points. view of a chain, video output 44.

[0070] O codificador de vídeo 28, decodificador de vídeo 48, o codificador de áudio 26, de decodificador de áudio 46, unidade de encapsulação 30, a unidade de recuperação de 52, e a unidade de encapsulação inversa 50 podem ser implementadas como qualquer um de uma variedade de circuitos de processamento apropriado, conforme o caso, tal como um ou mais microprocessadores, processadores de sinal digitais (DSPs), circuitos integrados de aplicação específica (ASICs), matrizes de portas programáveis de campo (FPGAs), circuitos lógicos discretos, software, hardware, firmware, ou quaisquer suas combinações. Cada codificador de vídeo 28 e decodificador de vídeo 48 pode ser incluído em um ou mais codificadores ou decodificadores, cada um dos quais pode ser integrado como parte de um codificador de vídeo/decodificador combinado (CODEC). Da mesma forma, cada um de codificador de áudio 26 e decodificador de áudio 46 podem ser incluídos em uma ou mais codificadores ou decodificadores, cada um dos quais pode ser integrado como parte de um codec combinado. Um aparelho, incluindo um codificador de vídeo 28, decodificador de vídeo 48, o codificador de áudio 26, um decodificador de áudio 46, unidade de encapsulação 30, a unidade de recuperação de 52, e/ou unidade de encapsulação inversa 50 pode compreender um circuito integrado, um microprocessador, e/ou um dispositivo de comunicação sem fio, tais como um telefone celular.[0070] The video encoder 28, video decoder 48, the audio encoder 26, audio decoder 46, encapsulation unit 30, recovery unit 52, and reverse encapsulation unit 50 may be implemented as any one of a variety of appropriate processing circuits, as applicable, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), logic circuits discrete, software, hardware, firmware, or any combination thereof. Each video encoder 28 and video decoder 48 may be included in one or more encoders or decoders, each of which may be integrated as part of a combined video encoder/decoder (CODEC). Likewise, each of audio encoder 26 and audio decoder 46 may be included in one or more encoders or decoders, each of which may be integrated as part of a combined codec. An apparatus including a video encoder 28, video decoder 48, audio encoder 26, an audio decoder 46, encapsulation unit 30, recovery unit 52, and/or reverse encapsulation unit 50 may comprise a integrated circuit, a microprocessor, and/or a wireless communication device, such as a cell phone.

[0071] O dispositivo de cliente 40, o dispositivo de servidor 60, e/ou o dispositivo de preparação de conteúdo 20 podem ser configurados para operar de acordo com as técnicas desta revelação. Para fins de exemplo, esta revelação descreve estas técnicas no que diz respeito ao dispositivo de cliente 40 e dispositivo de servidor 60. No entanto, deve ser entendido que dispositivo de preparação de conteúdo 20 pode ser configurado para executar estas técnicas, em vez de (ou além de) dispositivo de servidor 60.[0071] The client device 40, the server device 60, and/or the content preparation device 20 may be configured to operate in accordance with the techniques of this disclosure. For example purposes, this disclosure describes these techniques with respect to client device 40 and server device 60. However, it should be understood that content preparation device 20 may be configured to perform these techniques, instead of ( or in addition to) server device 60.

[0072] A unidade de encapsulação 30 pode formar unidades NAL que compreendem um cabeçalho que identifica um programa a qual pertence à unidade NAL, bem como uma carga, por exemplo, dados de áudio, dados de vídeo, ou dados que descreve o fluxo de transporte ou programa para a qual a unidade NAL corresponde. Por exemplo, em H.264/AVC, uma unidade NAL inclui um cabeçalho de 1 byte e uma carga útil de tamanho variável. Uma unidade NAL incluindo dados de vídeo na sua carga útil pode compreender vários níveis de granularidade de dados de vídeo. Por exemplo, uma unidade NAL pode compreender um bloco de dados de vídeo, uma pluralidade de blocos, uma fatia de dados de vídeo, ou uma imagem inteira de dados de vídeo. A unidade de encapsulação 30 pode receber os dados de vídeo codificados do codificador de vídeo 28, na forma de pacotes PES de fluxos elementares. A unidade de encapsulação 30 pode associar cada fluxo elementar com um programa correspondente.[0072] The encapsulation unit 30 can form NAL units that comprise a header that identifies a program to which the NAL unit belongs, as well as a payload, for example, audio data, video data, or data that describes the stream of transport or program to which the NAL unit corresponds. For example, in H.264/AVC, an NAL unit includes a 1-byte header and a variable-length payload. An NAL unit including video data in its payload can comprise various levels of video data granularity. For example, an NAL unit may comprise a block of video data, a plurality of blocks, a slice of video data, or an entire image of video data. The encapsulation unit 30 may receive the encoded video data from the video encoder 28 in the form of elementary stream PES packets. The encapsulation unit 30 may associate each elementary stream with a corresponding program.

[0073] A unidade de encapsulação 30 também pode montar unidades de acesso a partir de uma pluralidade de unidades NAL. Em geral, uma unidade de acesso pode compreender uma ou mais unidades NAL para representar um quadro de dados de vídeo, como também dados de áudio correspondentes ao quadro quando tais dados de áudio estão disponíveis. Uma unidade de acesso geralmente inclui todas as unidades NAL, por exemplo, tempo de uma saída, por exemplo, todos os dados de áudio e vídeo para uma instância do tempo. Por exemplo, se cada uma tem uma taxa de frames de 20 frames por segundo (fps), então cada instante de tempo pode corresponder a um intervalo de tempo de 0,05 segundos. Durante este intervalo de tempo, os quadros específicos para todas as vistas da mesma unidade de acesso (a mesma instância do tempo) podem ser processados simultaneamente. Em um exemplo, uma unidade de acesso pode compreender uma imagem codificada em um instante de tempo, que pode ser apresentada como uma imagem primária codificada.[0073] The encapsulation unit 30 can also assemble access units from a plurality of NAL units. In general, an access unit may comprise one or more NAL units for representing a frame of video data, as well as audio data corresponding to the frame when such audio data is available. An access unit typically includes all NAL units, e.g., time of an output, e.g., all audio and video data for an instance of time. For example, if each has a frame rate of 20 frames per second (fps), then each time instant can correspond to a time interval of 0.05 seconds. During this time interval, specific frames for all views of the same access unit (the same time instance) can be processed simultaneously. In one example, an access unit may comprise an image encoded at an instant of time, which may be presented as a primary encoded image.

[0074] Por conseguinte, uma unidade de acesso pode compreender todos os quadros de áudio e de vídeo de um exemplo comum temporal, por exemplo, todas as vistas correspondentes ao tempo X. Esta revelação também se refere a uma imagem codificada de um ponto de vista particular como um “componente de visualização.” Isto é, um componente de visualização pode compreender uma imagem codificada (ou frame) de um ponto de vista particular em um determinado momento. Por conseguinte, uma unidade de acesso pode ser definido como compreendendo todos os componentes de vista de um exemplo comum temporal. A ordem de decodificação de unidades de acesso não tem necessariamente de ser a mesma que a saída ou a ordem de exibição.[0074] Therefore, an access unit may comprise all audio and video frames of a common temporal instance, e.g., all views corresponding to time particular view as a “visualization component.” That is, a visualization component may comprise an encoded image (or frame) of a particular point of view at a particular time. Therefore, an access unit can be defined as comprising all view components of a common temporal instance. The decoding order of access units does not necessarily have to be the same as the output or display order.

[0075] Uma apresentação de mídia pode incluir uma descrição apresentação de mídia (MPD), o qual pode conter descrições de diferentes representações alternativas (por exemplo, serviços de vídeo, com diferentes qualidades) e a descrição pode incluir, por exemplo, o codec informações, um valor de perfil, e um valor de nível. Um MPD é um exemplo de um arquivo de manifesto, tal como o manifesto de arquivo 66. O dispositivo de cliente 40 pode recuperar o MPD de uma apresentação de mídia para determinar como acessar fragmentos de filmes de várias apresentações. Os fragmentos de filmes podem estar localizados em caixas de fragmentos de filme (caixas Moof) de arquivos de vídeo.[0075] A media presentation may include a media presentation description (MPD), which may contain descriptions of different alternative representations (e.g., video services, with different qualities) and the description may include, for example, the codec information, a profile value, and a level value. An MPD is an example of a manifest file, such as file manifest 66. The client device 40 may retrieve the MPD of a media presentation to determine how to access movie fragments from various presentations. Film fragments can be located in film fragment boxes (Moof boxes) of video files.

[0076] O arquivo de manifesto 66 (o qual pode compreender, por exemplo, um MPD) pode anunciar disponibilidade de segmentos de representações 68. Isto é, o MPD pode incluir informação indicando a hora em que um primeiro segmento de representações 68 torna-se disponível, assim como a informação indicando as durações de segmentos dentro de representações 68. Desta maneira, a unidade de recuperação 52 do dispositivo de cliente 40 pode determinar quando cada segmento está disponível, com base no tempo de início, bem como as durações dos segmentos que precedem um segmento particular.[0076] The manifest file 66 (which may comprise, for example, an MPD) may announce availability of representation segments 68. That is, the MPD may include information indicating the time at which a first representation segment 68 becomes available. if available, as well as information indicating the durations of segments within representations 68. In this way, the retrieval unit 52 of the client device 40 can determine when each segment is available, based on the start time, as well as the durations of the segments. segments that precede a particular segment.

[0077] Após a unidade de encapsulação 30 tem montado as unidades NAL e/ou unidades de acesso para um arquivo de vídeo com base nos dados recebidos, a unidade de encapsulação 30 transmite o arquivo de vídeo para a interface de saída 32 para a saída. Em alguns exemplos, a unidade de encapsulação 30 pode armazenar o arquivo de vídeo localmente ou enviar o arquivo de vídeo para um servidor remoto atráves de interface de saída 32, em vez de enviar o arquivo de vídeo diretamente para o dispositivo de cliente da interface de saída 40. 32 podem compreender, por exemplo, um transmissor, um transceptor, um dispositivo para escrita de dados num meio legível por computador, tal como, por exemplo, uma unidade óptica, uma unidade de suporte magnético (por exemplo, unidade de disquete), uma porta universal Serial bus (USB), uma interface de rede, ou outra interface de saída. A interface de saída 32 envia o arquivo de vídeo para um meio legível por computador, tais como, por exemplo, um sinal de transmissão, de um meio magnético, um meio óptico, uma memória, uma unidade de flash ou outra forma legível por computador.[0077] After the encapsulation unit 30 has assembled the NAL units and/or access units for a video file based on the received data, the encapsulation unit 30 transmits the video file to the output interface 32 for output . In some examples, the encapsulation unit 30 may store the video file locally or send the video file to a remote server via output interface 32, rather than sending the video file directly to the client device from the output interface 32. output 40. 32 may comprise, for example, a transmitter, a transceiver, a device for writing data to a computer-readable medium, such as, for example, an optical drive, a magnetic media drive (e.g., floppy disk drive ), a universal Serial bus (USB) port, a network interface, or other output interface. The output interface 32 outputs the video file to a computer-readable medium, such as, for example, a broadcast signal, a magnetic medium, an optical medium, a memory, a flash drive, or other computer-readable form. .

[0078] a interface de rede 54 pode receber uma unidade NAL ou unidade de acesso através da rede 74 e fornecer a unidade NAL ou unidade de acesso para Unidade de encapsulação inversa 50, através da unidade de recuperação 52. A unidade de encapsulação inversa 50 pode encapsular inversamente os elementos de um arquivo de vídeo em fluxos constituintes PES, desempacotar os fluxos PES para recuperar dados codificados, e enviar os dados codificados para qualquer decodificador de áudio 46 ou decodificador de vídeo 48, dependendo se os dados codificados é parte de um de áudio ou de vídeo corrente, por exemplo, como indicado por cabeçalhos de pacotes PES do fluxo. O decodificador de áudio 46 decodifica os dados de áudio codificados e envia os dados de áudio decodificados de saída de áudio 42, enquanto decodificador de vídeo 48 decodifica dados codificados de vídeo e envia os dados de vídeo decodificados, que podem incluir uma pluralidade de pontos de vista de uma corrente, a saída de vídeo 44.[0078] the network interface 54 may receive a NAL unit or access unit over the network 74 and provide the NAL unit or access unit to Reverse Encapsulation Unit 50 through the recovery unit 52. The Reverse Encapsulation Unit 50 may inversely encapsulate elements of a video file into constituent PES streams, unpack the PES streams to recover encoded data, and send the encoded data to either audio decoder 46 or video decoder 48, depending on whether the encoded data is part of a current audio or video stream, for example, as indicated by the stream's PES packet headers. Audio decoder 46 decodes the encoded audio data and outputs the decoded audio data to audio output 42, while video decoder 48 decodes encoded video data and outputs the decoded video data, which may include a plurality of audio points. view of a chain, video output 44.

[0079] Os diversos elementos do sistema 10 (por exemplo, o dispositivo de cliente 40, o dispositivo de preparação de conteúdo 20 e/ou o dispositivo de servidor 60) podem ser configurados para executar as várias técnicas desta revelação. Em geral, o exemplo de sistema 10 inclui vários elementos que podem ser configuradas para iniciar o consumo de uma apresentação de mídia DASH baseado no formato de arquivo de mídia de base ISO (ISO BMFF), ou um arquivo ISO BMFF segmentado, para que os segmentos são fornecidos através de camadas protocolo de Transporte de Codificação (LCT) entrega do objeto, por exemplo, o protocolo ROUTE sem o MPD (por exemplo, arquivo de manifesto 66) e sem a entrega de metadados associados entre Objeto Identificadores de Transporte (TOIs) e URLs (tais como o FDT, o EFDT, ou o cabeçalho de entidade em GFD ou ROUTE) e a sinalização MPD é fornecida por outros meios, por exemplo, o LCT Descrição de Instância de Sessão (LSID) em ROUTE, SDP em FLUTE, o cabeçalho de LCT, o ISO BMFF IS, ou semelhantes. Ou seja, dispositivo de cliente 40 pode iniciar consumo através da realização de arranque do serviço, que pode incluir o acesso a um serviço de ponto de entrada.[0079] The various elements of the system 10 (e.g., the client device 40, the content preparation device 20, and/or the server device 60) may be configured to perform the various techniques of this disclosure. In general, example system 10 includes various elements that can be configured to initiate consumption of a DASH media presentation based on the ISO base media file format (ISO BMFF), or a segmented ISO BMFF file, so that Segments are provided through the object delivery Coding Transport Protocol (LCT) layers, for example, the ROUTE protocol without the MPD (e.g. manifest file 66) and without the delivery of associated metadata between Transport Object Identifiers (TOIs). ) and URLs (such as the FDT, the EFDT, or the entity header in GFD or ROUTE) and MPD signaling is provided by other means, for example, the LCT Session Instance Description (LSID) in ROUTE, SDP in FLUTE, the LCT header, the ISO BMFF IS, or similar. That is, client device 40 may initiate consumption by performing service startup, which may include accessing an entry point service.

[0080] Os elementos do sistema 10 (tal como o dispositivo de cliente 40) também podem (adicionalmente ou alternativamente) ser configurado para consumir totalmente uma corrente unidirecional, isto é, uma distribuição de difusão, de acordo com as hipóteses de entrega acima.[0080] System elements 10 (such as client device 40) may also (additionally or alternatively) be configured to fully consume a unidirectional current, i.e., a broadcast distribution, in accordance with the above delivery assumptions.

[0081] Os elementos de sistema 10 também podem (adicionalmente ou alternativamente) ser configurado para iniciar uma apresentação DASH Meios sem o MPD (por exemplo, arquivo de manifesto de 66), mas depois do arranque inicial e desenrolar, o MPD pode ser recebida e processada (por exemplo, entregues pelo dispositivo de servidor 60 e recebido pelo dispositivo de cliente 40) a fim de obter informações mais ricas e para combinar com a entrega de banda larga/unidifusão.[0081] System elements 10 may also (additionally or alternatively) be configured to initiate a DASH Media presentation without the MPD (e.g., manifest file 66), but after initial startup and unrolling, the MPD may be received and processed (e.g., delivered by server device 60 and received by client device 40) in order to obtain richer information and to combine with broadband/unicast delivery.

[0082] O MPD pode conter apenas informações absolutamente necessárias para o ajuste de transmissão ou mudança de canal, onde um ou mais dos seguintes podem ser aplicadas: • Quando nenhuma informação MPD é absolutamente necessária, o MPD pode estar vazio. • Cópias MPD regulares (com algumas informações que não sejam absolutamente necessárias, por exemplo, só precisavam de algum acessório ou otimização) estão incluídas escassamente em alguns pontos de acesso aleatório (RAPs), e entre duas copias regulares MPD um MPD leve (com informações apenas absolutamente necessárias) está incluído em cada RAP.[0082] The MPD may contain only information absolutely necessary for transmission adjustment or channel switching, where one or more of the following may apply: • When no MPD information is absolutely necessary, the MPD may be empty. • Regular MPD copies (with some information that is not absolutely necessary, e.g. just needed some enhancement or optimization) are sparsely included in some Random Access Points (RAPs), and between two regular MPD copies a lightweight MPD (with information only absolutely necessary) is included in each RAP.

[0083] Os elementos de sistema 10 também podem (adicionalmente ou alternativamente) ser configurado para utilizar um tempo de transmissão de destino de cada pacote que é adicionada ao pacote ROUTE, refletindo um momento em que o receptor está a consumir (decodificação e renderização) os dados relativos para outros dados na mesma sessão de rotas, em que um ou mais dos seguintes se aplicam para o tempo de transmissão de destino: • Pelo qual esse tempo é assinalado no cabeçalho LCT. • Pelo qual esse tempo é assinalado no cabeçalho CC. • Pelo qual esse tempo é sinalizado em um cabeçalho de extensão. • Em que este tempo é um tempo relativo. • Em que desta vez é um tempo de relógio de parede absoluta tal como um tempo de protocolo de tempo de rede (NTP). • Em que este tempo é um tempo relativo e um tempo de liberação é sinalizado em um pacote, e o pacote só é liberado para o consumo quando o tempo de liberação é menor ou igual ao tempo de transmissão de destino.[0083] System elements 10 may also (additionally or alternatively) be configured to use a destination transmission time for each packet that is added to the ROUTE packet, reflecting a time at which the receiver is consuming (decoding and rendering) data relative to other data in the same route session, where one or more of the following applies for the destination transmission time: • By which that time is noted in the LCT header. • By which this time is noted in the CC header. • By which this time is signaled in an extension header. • In which this time is a relative time. • Where this time is an absolute wall clock time such as a Network Time Protocol (NTP) time. • Where this time is a relative time and a release time is signaled on a packet, and the packet is only released for consumption when the release time is less than or equal to the destination transmission time.

[0084] Os elementos de sistema 10 também podem (adicionalmente ou alternativamente) ser configurado para usar um sinalizador, adicionado ao pacote ROUTE, que reflete se o receptor está consumindo (decodificando e renderizando) os dados contidos no pacote quando está presente, em que um ou mais dos seguintes podem ser aplicadas: • Quando o sinalizador é igual a 1, o pacote é mantido pelo remetente, e não passou para o receptor para consumo. • Quando o sinalizador é igual a 0, o pacote é liberado pelo remetente para o receptor para consumo. • O valor do sinalizador deve ser necessariamente igual a 1 para o último pacote de um objeto.[0084] System elements 10 may also (additionally or alternatively) be configured to use a flag, added to the ROUTE packet, that reflects whether the receiver is consuming (decoding and rendering) the data contained in the packet when it is present, wherein One or more of the following may apply: • When the flag is equal to 1, the packet is retained by the sender, and not passed to the receiver for consumption. • When the flag is equal to 0, the packet is released by the sender to the receiver for consumption. • The flag value must necessarily be equal to 1 for the last packet of an object.

[0085] Deste modo, o sistema 10 pode implementar um desenho que é uma abordagem vantajosa para a eficiência da largura de banda, atraso de arranque inicial, a simplicidade, robustez, capacidade de extensão e razões de complexidade, sem quaisquer desvantagens significativas.[0085] In this way, system 10 can implement a design that is an advantageous approach for bandwidth efficiency, initial startup delay, simplicity, robustness, extensibility and complexity ratios, without any significant disadvantages.

[0086] Desta forma, e tal como explicado em maior detalhe abaixo, o dispositivo de servidor 60 representa um exemplo de um dispositivo para o envio de dados dos mídia incluindo uma interface de rede para a saída de dados de uma pluralidade de sessões de transporte de codificação em camadas (LCT), e um processador configurado para construir uma descrição de instância de sessão LCT (LSID) incluindo informação representativa de uma pluralidade de sessões de LCT, cada uma das sessões de LCT, incluindo dados de uma representação respectiva de uma de uma pluralidade de representações de uma apresentação de mídia de fluxo contínuo adaptável dinâmico sobre HTTP (DASH), em que a LSID indica correspondências entre as sessões de LCT e as representações, a saída LSID através da interface de rede, e os dados das representações nas sessões LCT correspondentes de saída através da interface de rede.[0086] In this way, and as explained in greater detail below, server device 60 represents an example of a device for sending media data including a network interface for outputting data from a plurality of transport sessions. layer coding system (LCT), and a processor configured to construct an LCT session instance description (LSID) including information representative of a plurality of LCT sessions, each of the LCT sessions including data from a respective representation of a of a plurality of representations of a dynamic adaptive streaming media presentation over HTTP (DASH), wherein the LSID indicates correspondences between the LCT sessions and the representations, the LSID output via the network interface, and the data of the representations in the corresponding outgoing LCT sessions via the network interface.

[0087] Do mesmo modo, o dispositivo de cliente 40 representa um exemplo de um aparelho para o cliente para receber dados dos mídia incluindo um ou mais decodificadores multimídia configurados para decodificar dados multimídia, uma interface de rede, configurado para receber uma descrição de instância de sessão de transporte de codificação em camadas (LCT), LSID, em que o LSID inclui informação representativa de uma pluralidade de sessões de LCT, cada uma das sessões de LCT, incluindo dados de uma respectiva uma de uma pluralidade de representações de um dinâmico adaptável ao vivo através de HTTP (DASH) apresentação mídia e dados de um ou mais das sessões de LCT, e um processador configurado para iniciar o consumo de uma ou mais das representações da apresentação de mídia DASH utilizam o LSID e sem o uso de um arquivo de manifesto para a apresentação de mídia DASH, em que para iniciar o consumo, o processador está configurado para receber, através a interface de rede, os pacotes das sessões de LCT, incluindo porções de dados de um ou mais das representações, e fornecer dados de pacote aos um ou mais decodificadores de mídia.[0087] Likewise, client device 40 represents an example of an apparatus for the client to receive media data including one or more multimedia decoders configured to decode multimedia data, a network interface, configured to receive an instance description session layered coding transport (LCT), LSID, wherein the LSID includes information representative of a plurality of LCT sessions, each of the LCT sessions including data from a respective one of a plurality of representations of a dynamic adaptive live over HTTP (DASH) presentation media and data from one or more of the LCT sessions, and a processor configured to initiate consumption of one or more of the representations of the DASH media presentation using the LSID and without the use of a manifest file for the DASH media presentation, wherein to initiate consumption, the processor is configured to receive, through the network interface, packets from the LCT sessions, including data portions of one or more of the representations, and provide packet data to one or more media decoders.

[0088] A figura 2 é um diagrama conceitual que ilustra os elementos de conteúdo de multimídia exemplares 102. O conteúdo de multimídia 102 pode corresponder ao conteúdo de multimídia 64 (figura 1), ou outro conteúdo de multimídia armazenado no meio de armazenamento 62. No exemplo da figura 2, o conteúdo de multimídia 102 inclui descrição apresentação de mídia (MPD) 104 e uma pluralidade de representações 110A-110N. Representação 110A inclui dados de cabeçalho opcional 112 e segmentos 114A-114N (segmentos 114), enquanto a representação 110N inclui dados de cabeçalho opcional 122 e segmentos 124A-124N (segmentos 124). A letra N é usada para designar o último fragmento de filme em cada uma das representações 110A, 110N como uma questão de conveniência. Em alguns exemplos, pode haver um número diferente de fragmentos de filme entre as representações 110A, 110N.[0088] Figure 2 is a conceptual diagram illustrating exemplary multimedia content elements 102. Multimedia content 102 may correspond to multimedia content 64 (Figure 1), or other multimedia content stored on storage medium 62. In the example of Figure 2, multimedia content 102 includes media presentation description (MPD) 104 and a plurality of representations 110A-110N. Representation 110A includes optional header data 112 and segments 114A-114N (segments 114), while representation 110N includes optional header data 122 and segments 124A-124N (segments 124). The letter N is used to designate the last film fragment in each of representations 110A, 110N as a matter of convenience. In some examples, there may be a different number of film fragments between representations 110A, 110N.

[0089] MPD 104 pode compreender uma estrutura de dados em separado a partir de representações 110A-110N. MPD 104 pode corresponder a manifestar arquivo 66 da figura 1. Do mesmo modo, representações 110A-110N podem corresponder às representações 68 da figura 1. Em geral, MPD 104 pode incluir os dados que geralmente descreve características de representações 110A-110N, como codificação e renderização características, conjuntos de adaptação, um perfil para o qual MPD 104 corresponde, digitem o texto da informação, informação ângulo da câmera, informações de classificação, truque informação do modo (por exemplo, a informação indicativa de representações que incluem sequências secundárias temporais), e/ou informação para obter períodos remotos (por exemplo, para a inserção de propaganda orientada em conteúdo de mídia durante a reprodução).[0089] MPD 104 may comprise a separate data structure from representations 110A-110N. MPD 104 may correspond to manifest file 66 of FIG. 1. Likewise, representations 110A-110N may correspond to representations 68 of FIG. 1. In general, MPD 104 may include data that generally describes features of representations 110A-110N, such as encoding and rendering features, adaptation sets, a profile to which MPD 104 corresponds, text type information, camera angle information, classification information, trick mode information (e.g., information indicative of representations that include secondary temporal sequences ), and/or information to obtain remote periods (e.g. for the insertion of targeted advertising into media content during playback).

[0090] Os dados do cabeçalho 112, quando presentes, podem descrever as características de segmentos 114, por exemplo, locais temporais de pontos de acesso aleatório (RAPs, também referidos como pontos de acesso de fluxo (SAPs)), cujos segmentos 114 incluem pontos de acesso aleatório, deslocamentos de byte para os pontos de acesso aleatório dentro de segmentos 114, localizadores de recurso uniforme (URLs) dos segmentos 114, ou outros aspectos dos segmentos 114. Os dados de cabeçalho 122, quando presentes, podem descrever as características semelhantes para segmentos 124. Adicionalmente ou alternativamente, essas características podem ser totalmente incluídas no MPD 104.[0090] Header data 112, when present, may describe the characteristics of segments 114, e.g., temporal locations of random access points (RAPs, also referred to as stream access points (SAPs)), which segments 114 include random access points, byte offsets for random access points within segments 114, uniform resource locators (URLs) of segments 114, or other aspects of segments 114. Header data 122, when present, may describe the characteristics similar for segments 124. Additionally or alternatively, these features may be fully included in the MPD 104.

[0091] Os segmentos 114, 124 incluem uma ou mais amostras de vídeo codificado, cada um dos quais podem incluir quadros ou fatias de dados de vídeo. Cada uma das amostras de vídeo codificadas de segmentos 114 pode ter características semelhantes, por exemplo, altura, largura, e os requisitos de largura de banda. Tais características podem ser descritos por dados de MPD 104, embora tais dados não estejam ilustrados no exemplo da figura 2. MPD 104 pode incluir as características conforme descritas pela especificação 3GPP, com a adição de qualquer ou toda a informação sinalizada descrito nesta revelação.[0091] Segments 114, 124 include one or more encoded video samples, each of which may include frames or slices of video data. Each of the encoded video samples of segments 114 may have similar characteristics, e.g., height, width, and bandwidth requirements. Such features may be described by data from MPD 104, although such data is not illustrated in the example of Figure 2. MPD 104 may include features as described by the 3GPP specification, with the addition of any or all of the signaled information described in this disclosure.

[0092] Cada um dos segmentos 114, 124 pode ser associado com um localizador uniforme de recursos único (URL). Assim, cada um dos segmentos 114, 124 pode ser independentemente recuperável utilizando um protocolo de rede de transmissão, tais como DASH. Desta maneira, um dispositivo de destino, tal como o dispositivo de cliente 40, que pode utilizar um pedido HTTP GET para recuperar segmentos 114 ou 124. Em alguns exemplos, o dispositivo de cliente 40 pode usar pedidos HTTP GET parciais para recuperar intervalos de bytes específicos de segmentos 114 ou 124.[0092] Each of segments 114, 124 may be associated with a unique uniform resource locator (URL). Thus, each of the segments 114, 124 may be independently recoverable using a transmission network protocol such as DASH. In this way, a target device, such as client device 40, may use an HTTP GET request to retrieve segments 114 or 124. In some examples, client device 40 may use partial HTTP GET requests to retrieve byte ranges. specific to segments 114 or 124.

[0093] A figura 3 é um diagrama de blocos que ilustra os elementos de um exemplo de arquivo de vídeo 150, o que pode corresponder a um segmento de uma representação, tal como um dos segmentos 114, para o arranjo de dados ilustrados no exemplo da figura 3. O arquivo de vídeo 150 pode ser dito para encapsular um segmento. Como descrito acima, arquivos de vídeo de acordo com o formato de arquivo de mídia de base ISO e prorrogações armazenam os dados em uma série de objetos, referido como “caixas”. No exemplo da figura 3, arquivo de vídeo 150 inclui caixa de tipo de arquivo (FTYP) 152, caixa de filme (MOOV) 154, caixas de índice de segmento (sidx) 162, caixa de fragmento de filme (Moof) 164, e caixa de fragmento filme de acesso aleatório (MFRA) 166. Embora a figura 3 represente um exemplo de um arquivo de vídeo, deve ser entendido que outros arquivos de mídia podem incluir outros tipos de dados de mídia (por exemplo, dados de áudio, dados de texto cronometrado, ou similares) que está estruturado de forma similar aos dados de arquivo de vídeo 150, de acordo com o formato de arquivo de mídia de base ISO e suas extensões.[0093] Figure 3 is a block diagram illustrating the elements of an example video file 150, which may correspond to a segment of a representation, such as one of the segments 114, for the data arrangement illustrated in the example of Figure 3. Video file 150 can be said to encapsulate a segment. As described above, video files according to the ISO base media file format and extensions store the data in a series of objects, referred to as “boxes”. In the example of Figure 3, video file 150 includes file type box (FTYP) 152, movie box (MOOV) 154, segment index boxes (sidx) 162, movie fragment box (Moof) 164, and random access movie fragment box (MFRA) 166. Although Figure 3 represents an example of a video file, it should be understood that other media files may include other types of media data (e.g., audio data, data timed text format, or the like) that is structured similarly to video file data 150 in accordance with the ISO base media file format and its extensions.

[0094] A caixa de tipo de arquivo (FTYP) 152 descreve geralmente um tipo de arquivo para arquivo de vídeo 150. Caixa de tipo de arquivo 152 pode incluir dados que identificam uma especificação que descreve um melhor uso arquivo de vídeo tipo caixa 150. Caixa de tipo de arquivo 152 pode em alternativa ser colocada antes de caixa MOOV 154, caixa de fragmento de filme 164, e/ou caixa MFRA 166.[0094] File type box (FTYP) 152 generally describes a file type for video file 150. File type box 152 may include data that identifies a specification that describes a best use video file type box 150. File type box 152 may alternatively be placed before MOOV box 154, film fragment box 164, and/or MFRA box 166.

[0095] Em alguns exemplos, um segmento, tal como o arquivo de vídeo 150, pode incluir uma caixa de atualização MPD (não mostrado) antes de caixa FTYP 152. A caixa de atualização MPD pode incluir informação indicando que um MPD correspondente a uma representação incluindo arquivo de vídeo 150 está a ser atualizado, juntamente com informações para atualizar o MPD. Por exemplo, a caixa de atualização do MPD pode fornecer um URI ou URL para um recurso a ser usado para atualizar o MPD. Como outro exemplo, a caixa de atualização do MPD pode incluir dados para atualização do MPD. Em alguns exemplos, o quadro de atualização MPD pode seguir-se imediatamente uma caixa de tipo de segmento de (STYP) (não mostrado) do arquivo de vídeo 150, onde a caixa de STYP pode definir um tipo de segmento para o arquivo de vídeo 150. A figura 7, discutida em maior detalhe abaixo, fornece informações adicionais em relação à caixa de atualização do MPD.[0095] In some examples, a segment, such as video file 150, may include an MPD update box (not shown) before the FTYP box 152. The MPD update box may include information indicating that an MPD corresponding to a representation including 150 video file is being updated along with information to update the MPD. For example, the MPD update box might provide a URI or URL to a resource to be used to update the MPD. As another example, the MPD update box may include data for updating the MPD. In some examples, the MPD update frame may immediately follow a Segment Type (STYP) box (not shown) of video file 150, where the STYP box may define a segment type for the video file. 150. Figure 7, discussed in greater detail below, provides additional information regarding the MPD update box.

[0096] A caixa MOOV 154, no exemplo da figura 3, inclui a caixa de cabeçalho de filme 156 (MVHD), da caixa de trilha (TRAK) 158, e uma ou mais caixas de extensão de filme (MVEX) 160. Em geral, a caixa MVHD 156 pode descrever as características gerais do arquivo de vídeo 150. Por exemplo, a caixa MVHD 156 pode incluir os dados que descrevem quando o arquivo de vídeo 150 foi originalmente criado, quando o arquivo de vídeo 150 foi modificado pela última, uma escala de tempo para o arquivo de vídeo 150, uma duração de reprodução de arquivo de vídeo 150, ou outros dados que geralmente descreve arquivo de vídeo 150.[0096] The MOOV box 154, in the example of Figure 3, includes the film header box 156 (MVHD), the track box (TRAK) 158, and one or more film extension boxes (MVEX) 160. In In general, the MVHD box 156 may describe the general characteristics of the video file 150. For example, the MVHD box 156 may include data describing when the video file 150 was originally created, when the video file 150 was last modified , a time scale for video file 150, a playback duration of video file 150, or other data that generally describes video file 150.

[0097] A caixa TRAK 158 pode incluir dados para uma faixa de arquivo de vídeo 150. A caixa TRAK 158 pode incluir uma caixa de cabeçalho de trilha (TKHD) que descreve características da trilha correspondendo à caixa TRAK 158. Em alguns exemplos, a caixa TRAK a 158 pode incluir imagens codificadas de vídeo, enquanto que em outros exemplos, as imagens codificadas de vídeo da trilha podem ser incluídas nos fragmentos de filme 164, os quais podem ser referenciados por dados de caixa TRAK 158 e/ou caixas sidx 162.[0097] TRAK box 158 may include data for a video file track 150. TRAK box 158 may include a track header box (TKHD) that describes characteristics of the track corresponding to TRAK box 158. In some examples, the TRAK box 158 may include encoded video images, whereas in other examples, the video encoded images of the track may be included in film fragments 164, which may be referenced by TRAK box data 158 and/or sidx boxes 162 .

[0098] Em alguns exemplos, arquivo de vídeo 150 pode incluir mais de uma faixa. Por conseguinte, a caixa MOOV 154 pode incluir um número de caixas TRAK igual ao número de trilhas no arquivo de vídeo 150. A caixa TRAK 158 pode descrever as características de uma trilha correspondente do arquivo de vídeo 150. Por exemplo, a caixa TRAK 158 pode descrever informação temporal e/ou espacial para a faixa correspondente. Uma caixa TRAK semelhante à caixa TRAK 158 MOOV caixa 154 de pode descrever as características de uma faixa de conjunto de parâmetros, quando a unidade de encapsulação 30 (figura 2) inclui uma faixa de conjunto de parâmetros de um arquivo de vídeo, tal como um arquivo de vídeo 150. A unidade de encapsulação 30 pode sinalizar a presença de mensagens SEI nível sequência na faixa de conjunto de parâmetros dentro da caixa de TRAK descrevendo a faixa de conjunto de parâmetros.[0098] In some examples, video file 150 may include more than one track. Therefore, the MOOV box 154 may include a number of TRAK boxes equal to the number of tracks in the video file 150. The TRAK box 158 may describe the characteristics of a corresponding track of the video file 150. For example, the TRAK box 158 may describe temporal and/or spatial information for the corresponding track. A TRAK box similar to the TRAK box 158 MOOV box 154 can describe the characteristics of a parameter set range, when the encapsulation unit 30 (FIG. 2) includes a parameter set range from a video file, such as a video file 150. The encapsulation unit 30 may signal the presence of sequence level SEI messages in the parameter set range within the TRAK box describing the parameter set range.

[0099] As caixas MVEX 160 podem descrever as características de fragmentos de filme correspondentes 164, por exemplo, para sinalizar que o arquivo de vídeo 150 inclui fragmentos de filme 164, além dos dados de vídeo incluídos dentro da caixa MOOV 154, se for o caso. No contexto da transmissão de dados de vídeo, imagens de vídeo codificado podem ser incluídas em fragmentos de filmes 164, em vez de na caixa MOOV 154. Por conseguinte, todas as amostras de vídeo codificado podem ser incluídas nos fragmentos de filme 164, em vez de na caixa MOOV 154.[0099] The MVEX boxes 160 may describe the characteristics of corresponding film fragments 164, for example, to signal that the video file 150 includes film fragments 164 in addition to the video data included within the MOOV box 154, if so. case. In the context of video data transmission, encoded video images may be included in movie fragments 164 rather than in the MOOV box 154. Therefore, all encoded video samples may be included in movie fragments 164 rather than in the MOOV box 154. in the MOOV 154 box.

[00100] A caixa MOOV 154 pode incluir um número de caixas MVEX 160 igual ao número de fragmentos de filme 164 no arquivo de vídeo 150. Cada uma das caixas de MVEX 160 pode descrever as características de um correspondente dos fragmentos de filmes 164. Por exemplo, cada caixa MVEX pode incluir um filme se estende caixa de cabeçalho (MEHD) que descreve uma duração temporal, para o correspondente fragmento dos fragmentos de filme 164.[00100] The MOOV box 154 may include a number of MVEX boxes 160 equal to the number of film fragments 164 in the video file 150. Each of the MVEX boxes 160 may describe the characteristics of a corresponding one of the film fragments 164. For For example, each MVEX box may include a movie extends header box (MEHD) that describes a temporal duration for the corresponding fragment of movie fragments 164.

[00101] Como referido acima, a unidade de encapsulação 30 pode armazenar uma sequência de dados estabelecida em uma amostra de vídeo que não inclui dados de vídeo codificados atuais. Uma amostra de vídeo pode geralmente corresponder a uma unidade de acesso, que é uma representação de uma imagem codificada segundo um exemplo de tempo específico. No contexto de AVC, a imagem codificada inclui uma ou mais unidades NAL VCL que contém a informação para construir todos os pixels da unidade de acesso e outras unidades não-VCL NAL associados, tal como mensagens SEI. Adequadamente, unidade de encapsulação 30 pode incluir um conjunto de dados de sequência, que podem incluir mensagens SEI nível da sequência, em um dos fragmentos de filmes 164. A unidade de encapsulação 30 pode sinalizar adicionalmente a presença de um conjunto de dados em sequência e/ou mensagens SEI em nível de sequência como estando presente em uma de fragmentos de filme 164 dentro da uma das caixas 160 MVEX correspondente ao de fragmentos de filmes 164.[00101] As noted above, the encapsulation unit 30 can store a data sequence established in a video sample that does not include actual encoded video data. A video sample can generally correspond to an access unit, which is a representation of an image encoded according to a specific time sample. In the AVC context, the encoded image includes one or more VCL NAL units that contain the information to construct all pixels of the access unit and other associated non-VCL NAL units, such as SEI messages. Suitably, encapsulation unit 30 may include a set of sequence data, which may include sequence level SEI messages, in one of the movie fragments 164. The encapsulation unit 30 may further signal the presence of a sequence data set and /or sequence-level SEI messages as being present in one of the movie fragments 164 within the one of the MVEX boxes 160 corresponding to the movie fragments 164.

[00102] As caixas SIDX 162 são elementos opcionais de arquivo de vídeo 150. Isto é, arquivos de vídeo em conformidade com o formato de arquivo 3GPP, ou outros tais formatos de arquivo, não necessariamente incluem caixas SIDX 162. De acordo com o exemplo do arquivo 3GPP formato, uma caixa SIDX pode ser usado para identificar um segmento secundário de um segmento (por exemplo, um segmento contido em arquivo de vídeo 150). O formato de arquivo 3GPP define um segmento secundário como “um conjunto independente de uma ou mais caixas de fragmentos de filme consecutivos com a caixa de dados de mídia e uma caixa contendo dados de mídia referenciados por uma caixa de fragmentos de filme correspondente deve vir após essa caixa de fragmento de filme e preceder a próxima caixa de fragmento de filme contendo informações sobre a mesma trilha”. O formato de arquivo 3GPP também indica que uma caixa SIDX “contendo uma seqüência de referências aos segmentos secundários do (sub) segmento documentado pela caixa. Os segmentos secundários referenciados são contíguos no tempo de apresentação. Da mesma forma, os bytes referidos por uma caixa Índice de Segmento são sempre contíguos dentro do segmento. o tamanho referenciado dá a contagem do número de bytes no material referenciado”.[00102] SIDX boxes 162 are optional elements of video file 150. That is, video files conforming to the 3GPP file format, or other such file formats, do not necessarily include SIDX boxes 162. According to the example of the 3GPP file format, a SIDX box can be used to identify a secondary segment of a segment (e.g., a segment contained in video file 150). The 3GPP file format defines a secondary segment as “an independent set of one or more film fragment boxes consecutive with the media data box and a box containing media data referenced by a corresponding film fragment box must come after this film fragment box and precede the next film fragment box containing information about the same track.” The 3GPP file format also indicates that a SIDX box “contains a sequence of references to the secondary segments of the (sub)segment documented by the box. The referenced secondary segments are contiguous in presentation time. Likewise, the bytes referred to by a Segment Index box are always contiguous within the segment. the referenced size gives the count of the number of bytes in the referenced material”.

[00103] As caixas SIDX 162 geralmente fornecem informação representativa de um ou mais segmentos secundários de um segmento incluído no arquivo de vídeo 150. Por exemplo, tal informação pode incluir tempos de reprodução em que segmentos secundários de início e/ou finais, deslocamentos byte para os segmentos secundários, quer os segmentos secundários incluem (por exemplo, começar com) um ponto de acesso corrente (SAP), um tipo para o SAP (por exemplo, se o SAP é uma imagem de renovação instantânea de decodificador (IDR), uma imagem limpa de acesso aleatório (CRA), uma imagem de acesso de link interrompido (BLA), ou semelhante), uma posição do SAP (em termos de tempo de reprodução e/ou byte offset) no segmento secundário, e semelhante.[00103] SIDX boxes 162 generally provide information representative of one or more secondary segments of a segment included in video file 150. For example, such information may include playback times at which secondary start and/or end segments, byte offsets for the secondary segments, whether the secondary segments include (for example, start with) a current access point (SAP), a type for the SAP (for example, if the SAP is a decoder instant renewal image (IDR), a clean random access image (CRA), a broken link access image (BLA), or the like), a position of the SAP (in terms of playback time and/or byte offset) in the secondary segment, and the like.

[00104] Os fragmentos de filme 164 podem incluir uma ou mais imagens codificadas de vídeo. Em alguns exemplos, os fragmentos de filme 164 podem incluir um ou mais grupos de imagens (GOP), cada um dos quais pode incluir um número de imagens de vídeo codificado, por exemplo, quadros ou fotografias. Além disso, como descrito acima, fragmentos de filme 164 podem incluir conjuntos de dados em sequência em alguns exemplos. Cada um dos fragmentos de filmes 164 pode incluir uma caixa de fragmento filme cabeçalho (MFHD, não mostrado na figura 3). A caixa MFHD pode descrever as características do fragmento filme correspondente, tal como um número de sequência para o fragmento de filme. Filme fragmenta 164 pode ser incluído a fim de número de sequência no arquivo de vídeo 150.[00104] Film fragments 164 may include one or more encoded video images. In some examples, film fragments 164 may include one or more groups of images (GOP), each of which may include a number of encoded video images, e.g., frames or photographs. Furthermore, as described above, film fragments 164 may include sequence data sets in some examples. Each of the movie fragments 164 may include a movie fragment header box (MFHD, not shown in Figure 3). The MFHD box may describe the characteristics of the corresponding film fragment, such as a sequence number for the film fragment. Film fragments 164 may be included in order of sequence number in video file 150.

[00105] A caixa MFRA 166 pode descrever pontos de acesso aleatório dentro de fragmentos de filme 164 do arquivo de vídeo 150. Isto pode ajudar com desempenho modos de truques, como realizar procura localizações temporais particulares (ou seja, tempos de reprodução) dentro de um segmento encapsulado pelo arquivo de vídeo 150. A caixa MFRA 166 é geralmente opcional e não precisa ser incluído em arquivos de vídeo, em alguns exemplos. Da mesma forma, um dispositivo de cliente, tal como o dispositivo de cliente 40, não precisa necessariamente de caixa MFRA 166 para fazer referência para decodificar corretamente e os dados de arquivo de vídeo 150. A caixa MFRA 166 exibição de vídeo pode incluir um número caixas de acesso aleatório de fragmento de trilha (TFRA) (não mostradas) igual ao número de trilhas de arquivo de vídeo 150, ou, em alguns exemplos, igual ao número de trilhas de mídia (por exemplo, trilhas de não sugestão) do arquivo de vídeo 150.[00105] The MFRA box 166 can describe random access points within movie fragments 164 of the video file 150. This can help with performance trick modes, such as performing searches for particular temporal locations (i.e., playback times) within a segment encapsulated by video file 150. The MFRA box 166 is generally optional and does not need to be included in video files, in some examples. Likewise, a client device, such as client device 40, does not necessarily need the MFRA box 166 to reference to correctly decode video file data 150. The MFRA video display box 166 may include a number track fragment random access (TFRA) bins (not shown) equal to the number of tracks of video file 150, or, in some examples, equal to the number of media tracks (e.g., non-cue tracks) of the file of video 150.

[00106] Em alguns exemplos, os fragmentos de filmes 164 podem incluir um ou mais pontos de acesso de fluxo (PAE), tais como imagens de IDR. Da mesma forma, a caixa MFRA 166 pode fornecer indicações de locais dentro de arquivo de vídeo de 150 dos SAPs. Por conseguinte, uma sequência secundária temporal do arquivo de vídeo 150 pode ser formada a partir de SAPs de arquivo de vídeo 150. A sequência secundária temporal também pode incluir outras imagens, tais como quadros P e/ou quadros B que dependem de PAE. Quadros e/ou fatias da sequência secundária temporal podem ser dispostos dentro dos segmentos, tais que os quadros/fatias da sequência secundária temporal que dependem de outros quadros/fatias da sequência secundária pode ser corretamente decodificados. Por exemplo, na disposição hierárquica de dados, os dados utilizados para a predição para outros dados também podem ser incluídos na sequência secundária temporal.[00106] In some examples, film fragments 164 may include one or more stream access points (PAE), such as IDR images. Likewise, the MFRA box 166 can provide indications of locations within the video file of 150 of the SAPs. Accordingly, a temporal subsequence of video file 150 may be formed from SAPs of video file 150. The temporal subsequence may also include other images, such as P-frames and/or B-frames that depend on PAE. Frames and/or slices of the temporal secondary sequence can be arranged within the segments, such that frames/slices of the temporal secondary sequence that depend on other frames/slices of the secondary sequence can be correctly decoded. For example, in hierarchical data arrangement, data used for prediction for other data can also be included in the temporal secondary sequence.

[00107] A figura 4 é um diagrama conceitual ilustrando um exemplo de cenário que muitas vezes surge na entrega de difusão. O cenário pode ser descrito como se segue: • Vários serviços são distribuídos (tipicamente em diferentes canais). • Serviços têm componentes de difusão e podem ter componentes de unidifusão/banda larga adicionais. • Tipicamente, os serviços incluem componentes diferentes, por exemplo, vídeo, áudio, subtítulos, áudio alternativo, vídeo alternativo, etc., que são descritos por metadados. • Na transmissão, cada componente pode ser enviado em uma sessão de transporte diferente, de tal forma que os componentes podem ser selecionados/filtrados. • Os componentes e serviços são multiplexados em nível de pacote.[00107] Figure 4 is a conceptual diagram illustrating an example scenario that often arises in broadcast delivery. The scenario can be described as follows: • Multiple services are distributed (typically across different channels). • Services have broadcast components and may have additional unicast/broadband components. • Typically, services include different components, e.g. video, audio, subtitles, alternate audio, alternate video, etc., which are described by metadata. • In transmission, each component can be sent in a different transport session, such that components can be selected/filtered. • Components and services are multiplexed at the packet level.

[00108] No exemplo da figura 4, há duas estações de radiodifusão de mídia separada 180A, 180B. Estação 180A fornece dados do programa de inicialização 182, incluindo LSID 184 e fragmentos de sinalização relacionados 186A-186N (186 fragmentos de sinalização). a estação 180A também fornece dados de áudio 188 (incluindo dados de áudio 188A e 188B mostrados na figura 4), os dados de vídeo 190 (incluindo dados de vídeo 190A e 190B na figura 4), os dados de texto cronometrados 192, vídeo dados realce camada 194 (incluindo os dados da camada de aumento de vídeo 194A e 194B mostrada na figura 4), e os dados para idiomas de áudio (196 alternativos, incluindo 196A alternativa de dados áudio língua e 196B mostrada na figura 4). Em um exemplo, a estação 180A fornece dados de inicialização 182 atráves de Protocolo de Datagrama de Usuário (UDP) de transporte utilizando Identificador de Sessão (TSI) 0, os dados de áudio 188 através de UDP usando TSI 1, os dados de vídeo 190 através de UDP usando TSI 2, dados da camada de melhoria de vídeo 194 através de banda larga, e os dados para idiomas de áudio alternativo 196 por meio de HTTP.[00108] In the example of figure 4, there are two separate media broadcasting stations 180A, 180B. Station 180A provides initialization program data 182, including LSID 184 and related signal fragments 186A-186N (186 signal fragments). station 180A also provides audio data 188 (including audio data 188A and 188B shown in FIG. 4), video data 190 (including video data 190A and 190B in FIG. 4), timed text data 192, video data enhancement layer 194 (including the video enhancement layer data 194A and 194B shown in Figure 4), and the data for audio languages (196 alternates, including 196A alternative audio language data and 196B shown in Figure 4). In one example, station 180A provides initialization data 182 over User Datagram Protocol (UDP) transport using Session Identifier (TSI) 0, audio data 188 over UDP using TSI 1, video data 190 via UDP using TSI 2, video enhancement layer data 194 via broadband, and data for alternate audio languages 196 via HTTP.

[00109] A estação 180B, neste exemplo, proporciona dados do programa de inicialização 200, incluindo LSID 202 e fragmentos de sinalização relacionados 204A-204N (204 fragmentos de sinalização). Estação 180B também fornece dados áudio 206 (incluindo dados de áudio 206A e 206B mostrados na figura 4), os dados de vídeo 208 (incluindo dados vídeo 208A e 208B na figura 4), e os dados a acessibilidade de áudio 210 (incluindo dados de linguagem acessibilidade de áudio 210A e 210B mostrada na figura 4). Em um exemplo, a estação 180A fornece dados do programa de inicialização 182 através de Protocolo de Datagrama de Usuário (UDP) usando Identificador de Sessão de Transporte (TSI) 0, os dados de áudio 188 através de UDP usando TSI 1, os dados de vídeo 190 através de UDP usando TSI 2, dados da camada de melhoria de vídeo 194 através de banda larga, e de idioma de áudio alternativa de dados 196 através de unidifusão (por exemplo, de acordo com HTTP).[00109] Station 180B, in this example, provides initialization program data 200, including LSID 202 and related signaling fragments 204A-204N (204 signaling fragments). Station 180B also provides audio data 206 (including audio data 206A and 206B shown in Figure 4), video data 208 (including video data 208A and 208B in Figure 4), and audio accessibility data 210 (including audio accessibility language 210A and 210B shown in figure 4). In one example, station 180A provides boot program data 182 via User Datagram Protocol (UDP) using Transport Session Identifier (TSI) 0, audio data 188 via UDP using TSI 1, audio data 188 via UDP using TSI 1, video 190 via UDP using TSI 2, video enhancement layer data 194 via broadband, and alternative audio language data 196 via unicast (e.g., in accordance with HTTP).

[00110] Em geral, as estações de 180A, 180B pode incluir dispositivos semelhantes ao dispositivo de preparação de conteúdo 20 e dispositivo de servidor 60 da figura 1. Em particular, as estações 180A, 180B podem incluir dispositivos separados uns dos outros, que executam uma funcionalidade semelhante àquela atribuída ao dispositivo de preparação de conteúdo 20 e/ou o dispositivo de servidor 60. Adicionalmente ou alternativamente, as estações de 180A, 180B pode preparar e fornecer dados de mídia os dados de mídia preparados para uma rede de distribuição de conteúdo (CDN), afiliadas estação local, empresas de cabo, ou outros distribuidores de conteúdo, o que pode distribuir os dados de mídia através de transmissão de rede ou unidifusão ou transmissão pelo ar.[00110] In general, stations 180A, 180B may include devices similar to the content preparation device 20 and server device 60 of Figure 1. In particular, stations 180A, 180B may include devices separate from each other, which perform a functionality similar to that assigned to the content preparation device 20 and/or the server device 60. Additionally or alternatively, the stations 180A, 180B can prepare and deliver the prepared media data to a content delivery network. (CDN), local station affiliates, cable companies, or other content distributors, which may distribute the media data via network transmission or unicast or over-the-air broadcast.

[00111] Embora não mostrado na figura 4, os fluxos de dados (ou seja, os dados do programa de inicialização 182, 200, dados de áudio 188, 206, dados de vídeo 190, 208, dados de texto sincronizados 192, dados de camada de realce vídeo 194, dados de linguagem de áudio alternativa 196, e a acessibilidade de áudio 210) podem ser organizados em segmentos, tais como segmentos de inicialização (ISS), incluindo os dados de configuração estática e uma sequência de segmentos meio contendo amostras codificadas de dados de mídia. Os segmentos podem incluir elementos suficientes para temporização, de tal modo que os dados podem ser decodificados e apresentados em conjunto com outras representações para o jogo sincronizado para fora. Por exemplo, segmentos de dados de áudio 188 e dados de vídeo 190 podem incluir dados de sincronização que tais áudio e vídeo são sincronizados durante a reprodução.[00111] Although not shown in Figure 4, the data streams (i.e., initialization program data 182, 200, audio data 188, 206, video data 190, 208, synchronized text data 192, video enhancement layer 194, alternative audio language data 196, and audio accessibility 210) may be organized into segments, such as initialization segments (ISS), including static configuration data and a sequence of middle segments containing samples encoded media data. The segments may include sufficient elements for timing such that the data may be decoded and presented together with other representations for synchronized play out. For example, segments of audio data 188 and video data 190 may include synchronization data such that audio and video are synchronized during playback.

[00112] Os segmentos seguem regras específicas de acordo com, por exemplo, DASH. Ou seja, os segmentos são objetos de dados, e o dispositivo de preparação de conteúdo 20 ou dispositivo de servidor 60 pode gerar segmentos independentemente de outros segmentos. Os segmentos seguem a ordem de decodificação, isto é, todos os segmentos com um número inferior têm tempos de decodificação inferior (isto é, mais cedo) do que os segmentos com números de segmento mais elevados. Além disso, o conteúdo pode ser unido em certas posições. Isso resulta em um novo período, para o qual cada representação receberá um IS novo. Há outros casos, quando um IS novo pode ser fornecido, mas a linha do tempo é contínua. Este pode ser o caso, por exemplo, se o IS incluir novos metadados.[00112] Segments follow specific rules according to, for example, DASH. That is, segments are data objects, and the content preparation device 20 or server device 60 can generate segments independently of other segments. Segments follow decoding order, that is, all segments with a lower segment number have lower (i.e., earlier) decoding times than segments with higher segment numbers. Additionally, content can be joined at certain positions. This results in a new period, for which each representation will receive a new IS. There are other cases when a new IS can be provided, but the timeline is continuous. This may be the case, for example, if the IS includes new metadata.

[00113] A figura 5 é um diagrama de blocos que ilustra exemplos de componentes de unidade de recuperação 52 do dispositivo de cliente 40 da figura 1. Neste exemplo, a unidade de recuperação de 52 inclui a unidade de multidifusão de IP 220, a unidade de configuração estática 222, a unidade de recepção 224 ROUTE, de cache 226, a unidade do servidor proxy 228, e DASH cliente 230. Em geral, o cliente pode recuperar DASH 230 segmentos de uma ou mais representações através da rede 74 (por exemplo, a partir do dispositivo de servidor 60) utilizando pedidos de unidifusão. Adicionalmente ou em alternativa, a unidade de recuperação 52 pode utilizar unidade de multidifusão de IP 220 para subscrever uma multidifusão de IP, para receber dados de multidifusão de IP incluindo segmentos de uma ou mais representações. Unidade de multidifusão de IP 220 pode passar segmentos recebidos 232 à unidade de recepção ROUTE 224, o qual pode armazenar os segmentos recebidos para armazenar em cache 226. O cliente DASH 230 pode, em seguida, solicitar os segmentos de unidade de servidor proxy 228. Nesta maneira, o cliente pode pedir DASH 230 segmentos tanto a partir de um endereço de IP do dispositivo de servidor 60, ou a partir de um endereço de local hospedeiro de dispositivo de cliente 40 que inclui a unidade de recuperação de 52. Em ambos os casos, o cliente DASH 230 pode recuperar os segmentos usando HTTP GET ou pedidos obter parciais. Assim, a unidade de recuperação de 52 pode geralmente receber segmentos através de unidifusão ou multidifusão de IP.[00113] Figure 5 is a block diagram illustrating examples of recovery unit 52 components of the client device 40 of Figure 1. In this example, the recovery unit 52 includes the IP multicast unit 220, the static configuration unit 222, ROUTE receiving unit 224, cache unit 226, proxy server unit 228, and DASH client 230. In general, the client may retrieve DASH segments 230 from one or more representations across the network 74 (e.g. , from the server device 60) using unicast requests. Additionally or alternatively, recovery unit 52 may use IP multicast unit 220 to subscribe to an IP multicast, to receive IP multicast data including segments from one or more representations. IP multicast unit 220 may pass received segments 232 to the ROUTE receiving unit 224, which may store the received segments to cache 226. The DASH client 230 may then request the segments from the proxy server unit 228. In this manner, the client may request DASH segments 230 either from an IP address of the server device 60, or from a local host address of client device 40 that includes the recovery unit 52. In both In these cases, the DASH client 230 may retrieve the segments using HTTP GET or partial GET requests. Thus, the recovery unit 52 can generally receive segments via IP unicast or multicast.

[00114] Se os dados são disponibilizados através de unidifusão, em seguida, os dados disponíveis são descritos no arquivo de manifesto (por exemplo, a Descrição de Apresentação de Mídia (MPD)), utilizando conceitos DASH como a Apresentação de Mídia, Períodos, Conjuntos de adaptação, Representações e segmentos. Em implementações básicas para a entrega de transmissão unidirecional de DASH mídia Apresentações, propõe-se para distribuir o MPD e os segmentos de dados como objetos regulares usando um protocolo de entrega de objeto tal como ROUTE, FLUTE ou FCAST. O receptor de objeto pode, então, utilizar os objetos recuperados a fim de proporcionar uma Apresentação de Mídia de um servidor local para um cliente DASH como mostrado nas figuras 1 e 5 (utilizando como exemplo ROUTE, mas tais técnicas são também aplicáveis à taça ou FCAST bem). Os segmentos são distribuídos de modo a que as URLs na MPD são atribuídas aos objetos entregues no protocolo de entrega do objeto, por exemplo, através de uma tabela de envio de arquivos (FDT), um FDT estendido (EFDT), ou como parte do objeto utilizando entidade HTTP cabeçalhos.[00114] If data is made available via unicast, then the available data is described in the manifest file (e.g., the Media Presentation Description (MPD)), using DASH concepts such as Media Presentation, Periods, Adaptation sets, Representations and segments. In basic implementations for unidirectional streaming delivery of DASH Media Presentations, it is proposed to distribute the MPD and data segments as regular objects using an object delivery protocol such as ROUTE, FLUTE, or FCAST. The object receiver can then use the retrieved objects to provide a Media Presentation from a local server to a DASH client as shown in Figures 1 and 5 (using ROUTE as an example, but such techniques are also applicable to cup or FCAST well). Segments are distributed so that URLs in the MPD are assigned to objects delivered in the object delivery protocol, for example, via a File Send Table (FDT), an Extended FDT (EFDT), or as part of the object using HTTP entity headers.

[00115] O emissor (por exemplo, o dispositivo de servidor 60 ou um dispositivo semelhante) proporciona os objetos de modo a que os segmentos são recebidos pelo dispositivo de cliente 40 antes dos respectivos tempos de disponibilidade de segmento anunciados no MPD. O dispositivo de servidor 60 (ou dispositivo de preparação de conteúdo 20) empacota os segmentos e multiplexa os pacotes em conformidade. Os objetos podem ser separados por diferentes identificadores objeto de transporte (TOIs) e a atribuição de URLs é fornecido como mencionado acima. Em uma configuração de envio de mais sofisticado, todos os segmentos de uma Representação são entregues em uma sessão dedicada, por exemplo, usando uma porta dedicada de Protocolo de Datagrama de Usuário (UDP) ou uma sessão dedicada de Transporte de Código em Camada (LCT) identificada por um identificador de sessão de transporte único (TSI). Essa atribuição permite que o receptor selecione ou ignore sessões inteiras com base na seleção de Representações pelo cliente DASH 230.[00115] The sender (e.g., the server device 60 or a similar device) provides the objects so that the segments are received by the client device 40 before the respective segment availability times advertised in the MPD. The server device 60 (or content preparation device 20) packages the segments and multiplexes the packets accordingly. Objects can be separated by different transport object identifiers (TOIs) and the assignment of URLs is provided as mentioned above. In a more sophisticated delivery configuration, all segments of a Representation are delivered in a dedicated session, for example, using a dedicated User Datagram Protocol (UDP) port or a dedicated Layer Code Transport (LCT) session. ) identified by a unique transport session identifier (TSI). This assignment allows the receiver to select or skip entire sessions based on the selection of Representations by the DASH 230 client.

[00116] No entanto, o fornecimento de uma apresentação de mídia sobre transmissão pode criar alguns desafios para o remetente, como o remetente pode precisar para prever o tempo de entrega e processamento, a fim de definir adequadamente os tempos de disponibilidade segmento no MPD. Se, por algum motivo, o sistema de distribuição tem mais ou menos atraso do que o esperado, o desempenho do cliente DASH 230 ou outro jogador pode ser afetado negativamente. A reprodução inicia-se pode ser demasiado cedo ou demasiado tarde. A reprodução de partida cedo demais pode resultar em uma tenda de reprodução de mídia, e a reprodução a partir-se demasiado tarde pode resultar numa mudança de canal mais lento e uma maior latência de ponta a ponta do que seria possível. Outro problema é que, antes de cliente DASH 230 fazendo uso dos segmentos e dos meios de comunicação contidos, o cliente DASH 230 pode precisar receber o FDT (ou uma estrutura de dados equivalente) e o MPD. Para frequentes pontos de acesso aleatório, esta pode aumentar a sobrecarga de metadados.[00116] However, providing a media presentation over transmission may create some challenges for the sender, as the sender may need to predict delivery and processing time in order to appropriately set segment availability times in the MPD. If, for some reason, the distribution system has more or less delay than expected, the performance of the DASH 230 client or other player may be negatively affected. Playback starts may be too early or too late. Starting playback too early can result in stalled media playback, and starting playback too late can result in slower channel switching and greater end-to-end latency than otherwise possible. Another problem is that, before the DASH client 230 makes use of the segments and the contained media, the DASH client 230 may need to receive the FDT (or an equivalent data structure) and the MPD. For frequent random access points, this can increase metadata overhead.

[00117] Como discutido em maior detalhe acima e abaixo, respectivamente, figura 1 e 6 ilustram exemplos de envio de infra-estruturas. Mais particularmente, a figura 6 é um diagrama de blocos que ilustra um exemplo de uma arquitetura de transmissor de base 240 que proporciona diferentes opções de envio, de acordo com as técnicas da presente revelação. Neste exemplo, a arquitetura de emissor 240 inclui múltiplas taxas de bits meios off-line codificador 244, codificador de mídia ao vivo de múltiplas taxas de bits 248, unidade de inserção de anúncio (anúncio) 252, a unidade de DASH desligada autoria 250, unidade DASH autoria vivo 256, o servidor de HTTP emulação vivo 258, HTTP vivo servidor 260, e ROUTE servidor 262. Nesse exemplo, codificador de mídia fora de linha de múltiplas taxas de bits 244 codifica mídia fora de linha de um ou mais conjuntos de áudio/vídeo (A/V) do conteúdo de origem 242, enquanto o codificador de mídia ao vivo de múltiplas taxas de bits 248 codifica um, ou ambos, conteúdo de origem 246A A/V e conteúdo ao vivo A/V 246B. Um conteúdo de origem A/V 246A pode representar o conteúdo pré-gravado, enquanto o conteúdo ao vivo A/V 246B pode representar o conteúdo a ser capturado em tempo real, por exemplo, um evento de notícias ao vivo, um evento desportivo, ou outro tal evento ao vivo.[00117] As discussed in greater detail above and below, respectively, Figures 1 and 6 illustrate examples of sending infrastructures. More particularly, Figure 6 is a block diagram illustrating an example of a base transmitter architecture 240 that provides different sending options in accordance with the techniques of the present disclosure. In this example, the emitter architecture 240 includes multiple bitrate offline media encoder 244, multibitrate live media encoder 248, ad insertion unit (ad) 252, offline DASH authoring unit 250, vivo authoring DASH unit 256, vivo emulation HTTP server 258, vivo HTTP server 260, and ROUTE server 262. In this example, multi-bitrate offline media encoder 244 encodes offline media from one or more sets of audio/video (A/V) of the source content 242 , while the multi-bitrate live media encoder 248 encodes one or both of the A/V source content 246A and the A/V live content 246B. A/V source content 246A may represent pre-recorded content, while A/V live content 246B may represent content to be captured in real time, e.g., a live news event, a sporting event, or other such live event.

[00118] O codificador de mídia fora de linha de múltiplos bits 244 fornece o conteúdo de mídia codificado para a unidade adaptada à linguagem fora de linha DASH 250. A unidade adaptada à linguagem fora de linha DASH 250 pode geralmente preparar dados multimídia codificados para o transporte através de, por exemplo, DASH. Por exemplo, para dados de vídeo, a unidade de desligada DASH autoria 250 pode preparar segmentos, incluindo um conjunto de quadros de vídeo codificados, que podem incluir uma armação de vídeo do ponto de acesso aleatório (RAP). Anúncio unidade de inserção 252 pode preparar o conteúdo anúncio para inserção em pontos apropriados de um fluxo de mídia preparado pelo servidor HTTP emulação vivo 258. Da mesma forma, a unidade DASH desligada autoria 250 pode fornecer segmentos preparados de uma ou mais representações de mídia para HTTP servidor de emulação ao vivo 258.[00118] The multi-bit off-line media encoder 244 provides the encoded media content to the DASH 250 off-line language adapted unit. The DASH 250 off-line language adapted unit can generally prepare encoded multimedia data for the transport via, for example, DASH. For example, for video data, the offline DASH authoring unit 250 may prepare segments including a set of encoded video frames, which may include a random access point (RAP) video frame. Ad insertion unit 252 may prepare ad content for insertion at appropriate points of a media stream prepared by the vivo emulation HTTP server 258. Likewise, the offline DASH authoring unit 250 may provide prepared segments of one or more media representations to HTTP live emulation server 258.

[00119] Em geral, o servidor de emulação ao vivo HTTP 258 emula um servidor de mídia ao vivo, tal como o servidor ao vivo HTTP 260. Por exemplo, o servidor ao vivo HTTP 258 pode sinalizar os tempos de disponibilidade para segmentos de várias representações (representações, por exemplo, de áudio e de vídeo, bem como representações de texto cronometrado em alguns exemplos). O servidor ao vivo HTTP 258 pode fornecer os segmentos de servidor ROUTE 262, que pode saída dos segmentos em determinadas épocas através de rota usando multidifusão de IP, com base em sugestão e informações de tempo 254. Adicionalmente ou em alternativa, o servidor ROUTE 262 pode receber conteúdo ao vivo DASH servidor HTTP 260, que recebe o conteúdo ao vivo de unidade DASH 256, o qual pode preparar o conteúdo ao vivo DASH a partir de dados multimídia codificados recebidos a partir de codificador de mídia ao vivo de múltiplas taxas de bits 248. Embora um único codificador de mídia ao vivo de múltiplas taxas de bits 248 seja mostrado neste exemplo, deve ser entendido que uma multiplicidade de codificadores podem ser empregues para a codificação de dados de mídia vivo, em alguns exemplos.[00119] In general, the HTTP 258 live emulation server emulates a live media server, such as the HTTP 260 live server. For example, the HTTP 258 live server may signal availability times for segments of various representations (e.g. audio and video representations, as well as timed text representations in some examples). The HTTP live server 258 may provide the segments to the ROUTE server 262, which may output the segments at certain times via route using IP multicast, based on suggestion and timing information 254. Additionally or alternatively, the ROUTE server 262 can receive live content DASH HTTP server 260, which receives live content from DASH unit 256, which can prepare DASH live content from encoded multimedia data received from multi-bitrate live media encoder 248. Although a single multi-bitrate live media encoder 248 is shown in this example, it should be understood that a plurality of encoders may be employed for encoding live media data in some examples.

[00120] A arquitetura de emissor 240 pode fornecer um ou ambos de conteúdo sob demanda como um serviço pseudo ao vivo e/ou um serviço ao vivo gerado usando DASH. Além disso, a arquitetura remetente 240 pode incluir ferramentas que suportam anúncio de inserção (ad), como unidade de inserção de anúncios 252. Outra opção é adicionar um pouco de robustez para correr, por exemplo, através do envio de vários períodos, a fim de permitir ressincronização usando o nível de MPD e/ou o nível de segmento. O conteúdo pode ser disponibilizado em um serviço HTTP de tal modo que clientes que estão conectados através de unidifusão (por exemplo, através da rede 74) pode aceder a toda ou partes do serviço através de unidifusão. Um exemplo de caso de utilização é a distribuição por meio de um protocolo de entrega de arquivo. Isto é, arquitetura remetente 240 pode entregar os objetos gerados DASH (MPD, segmentos ou outros objetos dados) através de um protocolo de entrega de arquivo, por exemplo, FLUTE, FCAST, MPEG meio de transporte (MMT) Genérico Entrega Arquivo (GFD), ou ROUTE. No caso de fluxo contínuo ao vivo, uso de ROUTE pode ser preferível, como ROUTE suporta capacidades em tempo real e mapeiam os objetos de forma adequada para os pacotes entregues sobre multidifusão de IP e, potencialmente, em seguida, sobre uma camada física transmitida tais como DVB- T2 com a encapsulação genérica de fluxo (GSE) ou uma tecnologia definida por ATSC 3.0.[00120] The sender architecture 240 may provide either or both of on-demand content as a pseudo live service and/or a live service generated using DASH. Additionally, the sender architecture 240 may include tools that support insertion advertising (ad), such as ad insertion unit 252. Another option is to add some robustness to run, for example, by sending multiple periods in order to allow resynchronization using the MPD level and/or the segment level. Content may be made available on an HTTP service such that clients that are connected via unicast (e.g., via network 74) can access all or parts of the service via unicast. An example use case is distribution via a file delivery protocol. That is, sender architecture 240 can deliver the generated DASH objects (MPD, segments or other data objects) via a file delivery protocol, e.g., FLUTE, FCAST, MPEG Medium Transport (MMT), Generic File Delivery (GFD) , or ROUTE. In the case of live streaming, use of ROUTE may be preferable, as ROUTE supports real-time capabilities and maps objects appropriately to packets delivered over IP multicast and potentially then over a physical layer transmitted such such as DVB-T2 with Generic Stream Encapsulation (GSE) or a technology defined by ATSC 3.0.

[00121] Tipicamente, para Serviço de Multidifusão Difusão de Multimídia (MBMS), MBMS melhoradas (eMBMS), e ATSC 3.0, uma abordagem de cima para baixo para a entrada de serviço é considerada: • Pode haver um ponto de entrada de serviço, por exemplo, uma página HTML-5 contendo um MPD ou um próprio MPD. • O serviço de fluxo contínuo pode ser descrito por um MPD que contém múltiplos componentes de mídia, cada documentado em um ou mais conjuntos de adaptação para a seleção adequada, incluindo metadados, classificação, acessibilidade, etc. • Cada Conjunto de Adaptação pode conter uma ou várias representações. • certas representações estão disponíveis na transmissão e construir um serviço básico. • Outras estão disponíveis em unidifusão, a fim de enriquecer e melhorar a apresentação. • Para inicializar o serviço, o MPD é necessário e o MPD controla o tempo e a reprodução.[00121] Typically, for Multicast Multimedia Service (MBMS), Enhanced MBMS (eMBMS), and ATSC 3.0, a top-down approach to service entry is considered: • There may be a service entry point, for example, an HTML-5 page containing an MPD or an MPD itself. • The streaming service can be described by an MPD that contains multiple media components, each documented in one or more adaptation sets for appropriate selection, including metadata, classification, accessibility, etc. • Each Adaptation Set can contain one or more representations. • Certain representations are available in the broadcast and build a basic service. • Others are available in unicast, in order to enrich and improve the presentation. • To initialize the service, MPD is required and MPD controls timing and playback.

[00122] O seguinte foi considerado como dados de acesso aleatório: • Para DASH sobre FLUTE conforme definido no MBMS: o A suposição é que certos fragmentos de metadados, ou seja, o pacote de descrição de serviço de usuário (USDB) e Protocolo de Descrição de Sessão (SDP) são estáticos e no cache. o Os dados que precisa ser adquirido em tempo real são os seguintes: FDT Instância, MPD, IS e segmento de mídia começando com um Grupo Fechado de Imagens (GOP) ponto de acesso aleatório (RAP). A exigência RAP-GOP fechado é uma restrição das implementações atuais. A coleta de dados necessários é referida como um grupo. o O primeiro pacote de FDT é o primeiro pacote de um grupo, ou seja, este pacote tem de ser recebidos e, em seguida, os seguintes pacotes restantes que estão associados a este grupo. o Para potencialmente entregar os dados para o cliente DASH para reprodução, pelo menos, um segmento completo deve ser recebido, ou seja, somente após recepção completa o segmento está “disponível” e pode ser programado para ser solicitado pelo cliente DASH. O cliente DASH vai então avançar e programar a reprodução do segmento quer seja através da geração de um armazenamento apropriado ou aderindo às instruções do atraso Apresentação sugerido na MPD. O Note-se que este procedimento é equivalente ao painel base ao longo do segmento ROUTE.[00122] The following has been considered as random access data: • For DASH over FLUTE as defined in the MBMS: o The assumption is that certain metadata fragments, i.e., the User Service Description Package (USDB) and Data Protocol Session Description (SDP) are static and cached. o The data that needs to be acquired in real time are the following: FDT Instance, MPD, IS and media segment starting with a Closed Group of Images (GOP) random access point (RAP). The closed RAP-GOP requirement is a restriction of current implementations. The necessary data collection is referred to as a group. o The first packet of FDT is the first packet of a group, i.e. this packet has to be received and then the following remaining packets that are associated with this group. o To potentially deliver the data to the DASH client for playback, at least one complete segment must be received, i.e., only after complete reception is the segment “available” and can be scheduled to be requested by the DASH client. The DASH client will then go ahead and schedule playback of the segment either by generating appropriate storage or adhering to the Presentation delay instructions suggested in the MPD. Note that this procedure is equivalent to the base panel along the ROUTE segment.

[00123] A figura 7 é um diagrama conceitual que ilustra exemplos de diferentes aspectos de entrada de serviço no exemplo de DASH através FLUTE. Em particular, a figura 7 ilustra uma entrada exemplo serviço 280, em que o protocolo de Internet e endereço de porta (PI), juntamente com MPD URL referência pode ser usado para recuperar dados. Em particular, a entrada de serviço 280 ilustra que um dispositivo de cliente, tal como o dispositivo de cliente 40, pode utilizar a tabela de entrega arquivo (FDT) 288 para recuperar o MPD 284, e, em seguida, usar FDT 288 e MPD 284 para recuperar segmento de inicialização 282 e o segmento de mídia 286.[00123] Figure 7 is a conceptual diagram illustrating examples of different aspects of service entry in the example of DASH through FLUTE. In particular, Figure 7 illustrates an example service entry 280, in which the Internet Protocol and port address (PI) along with MPD URL reference can be used to retrieve data. In particular, service entry 280 illustrates that a client device, such as client device 40, can use the file delivery table (FDT) 288 to retrieve the MPD 284, and then use FDT 288 and MPD 284 to recover boot segment 282 and media segment 286.

[00124] A figura 7 também ilustra a dependência de processamento 290 entre estes diferentes elementos. Em particular, FDT 288 é independente, MPD 284 é dependente de FDT 288, segmento de inicialização 282 é dependente de FDT 288 e MPD 284, e segmento de mídia 286 é dependente de cada um dos FDT 288, DMP 284, e segmento de inicialização 282.[00124] Figure 7 also illustrates the processing dependency 290 between these different elements. In particular, FDT 288 is independent, MPD 284 is dependent on FDT 288, initialization segment 282 is dependent on FDT 288 and MPD 284, and media segment 286 is dependent on each of FDT 288, DMP 284, and initialization segment. 282.

[00125] A figura 7 ilustra ainda uma ordem de envio típico 292, da esquerda para a direita. Por causa de processamento dependência 290, de acordo com a ordem de envio típico 292, FDT 288 são enviadas antes MPD 284, que é enviado antes segmento de inicialização 282, a qual é enviada, antes dos pacotes de segmento um ou mais meios de comunicação 286A, 286B (que formam a totalidade ou parte dos meios de comunicação segmento 286). • Para DASH sobre a rota: o Neste caso, a suposição é que a sessão Instância Descrição LCT (LSID) está disponível em cache de um dispositivo receptor, ou seja, o receptor tem informações sobre as sessões programadas e que é atribuído a cada uma das sessões de transporte LCT, o Os dados a serem adquiridas em tempo real podem incluir o seguinte: EFDT Instância, MPD, IS e segmento de mídia começando com um GOP RAP fechado. O GOP fechado requisito RAP é uma restrição das implementações atuais. A coleta de dados necessários é referida como um grupo. Na discussão desta descrição, a remoção do EFDT e o MPD são propostos. o O EFDT é o primeiro pacote de um grupo, ou seja, este pacote tem de ser recebido e, em seguida, o pacotes restantes que estão associados a este grupo seguinte. o Em um modo de funcionamento, o modo de recepção baseada em segmentos como discutido acima seria viável. No entanto, como ROUTE suporta mídia Entrega Evento (MDE) entrega com base, o cliente DASH e/ou o mecanismo de processamento ISO BMFF pode iniciar reprodução no início no momento em que um suficientemente grande prefixo do segmento de mídia é recebido. Neste caso, a fim de potencialmente entregar os dados para o cliente DASH para reprodução, o MDE precisa estar disponível e pode ser programado para ser solicitado pelo cliente DASH. O cliente DASH, então, progredir e agendar a reprodução do prefixo dos segmentos de mídia para acelerar o atraso inicial. O que é relevante e precisa ser considerado é uma maneira que a disponibilidade e os tempos de decodificar (tipicamente idênticos) são adequadamente derivados.[00125] Figure 7 further illustrates a typical shipping order 292, from left to right. Because of dependency processing 290, according to the typical sending order 292, FDT 288 are sent before MPD 284, which is sent before initialization segment 282, which is sent before the segment packets one or more media 286A, 286B (which form all or part of the media segment 286). • For DASH over route: o In this case, the assumption is that the Session Instance Description LCT (LSID) is available in cache of a receiving device, i.e. the receiver has information about the scheduled sessions and what is assigned to each of LCT transport sessions, the data to be acquired in real time may include the following: EFDT Instance, MPD, IS and media segment starting with a closed GOP RAP. The GOP closed RAP requirement is a restriction of current implementations. The necessary data collection is referred to as a group. In the discussion of this description, the removal of EFDT and MPD are proposed. o The EFDT is the first packet of a group, that is, this packet must be received and then the remaining packets that are associated with this group follow. o In one mode of operation, the segment-based reception mode as discussed above would be viable. However, because ROUTE supports Media Delivery Event (MDE) based delivery, the DASH client and/or the ISO BMFF processing engine can start playback at the beginning at the time a sufficiently large media segment prefix is received. In this case, in order to potentially deliver the data to the DASH client for replay, the MDE needs to be available and can be programmed to be requested by the DASH client. The DASH client will then progress and schedule prefix playback of the media segments to speed up the initial delay. What is relevant and needs to be considered is a way that availability and (typically identical) decode times are appropriately derived.

[00126] A figura 8 é um diagrama conceitual que mostra outro conjunto de exemplos de aspectos de uma entrada de serviço 300 de um exemplo de entrega de dados DASH através ROUTE. Neste exemplo, um FDT estendida (EFDT) 302 contém um mapeamento de TOIs a URLs e o tipo de conteúdo para o MPD 306, Inicialização Segmento 304, e segmento de mídia 310 (formado por evento de segmento de mídia de entrega (MDE) 308 A e segmento de mídia 308B restante). De um ponto de vista do processamento (isto é, como se mostra na dependência de processamento 312), o acesso aos meios de segmento 310 com os dados de mídia depende segmento de inicialização 304, DMP 306, e 302. EFDT segmento de inicialização 304 depende de processamento 306 e MPD EFDT 302. E o processamento de MPD 306 depende do processamento de EFDT 302. a fim de permitir que o referido processamento, a fim de enviar 314 de pacotes pode ser como mostrado na figura 7, isto é, EFDT 302, então MPD 306, então a inicialização segmento 304, e então os pacotes de segmento mídia (por exemplo, segmento de mídia MDE 308A, seguido por segmentos de meios restante 308B).[00126] Figure 8 is a conceptual diagram showing another set of example aspects of a service entry 300 of an example of DASH data delivery via ROUTE. In this example, an Extended FDT (EFDT) 302 contains a mapping of TOIs to URLs and content type for the MPD 306, Initialization Segment 304, and media segment 310 (formed by media segment delivery event (MDE) 308 A and remaining 308B media segment). From a processing point of view (i.e., as shown in processing dependency 312), access to the media segment 310 with the media data depends on initialization segment 304, DMP 306, and 302. EFDT initialization segment 304 depends on MPD processing 306 and EFDT 302. And the processing of MPD 306 depends on the processing of EFDT 302. In order to enable said processing, in order to send 314 packets can be as shown in Figure 7, that is, EFDT 302, then MPD 306, then the initialization segment 304, and then the media segment packets (e.g., MDE media segment 308A, followed by remaining media segments 308B).

[00127] A recepção específica para ROUTE tem sido documentada como segue: • O LSID descreve a combinação IP/porto e sessões LCT diferentes. • componentes de mídia diferentes representados em arquivos ISO BMFF segmentadas são associado ao e atribuídos exclusivamente a uma combinação de IP/porta/TSI. • O serviço é descrito por uma URL MPD. • O receptor ROUTE recupera objetos para um componente/serviço de canal. • Na recepção dos objetos, o receptor ROUTE atribui um URL a cada objeto utilizando o FDT/EFDT (ou, possivelmente, o modo de entidade). • cliente DASH recebe MPD URL, obtém do cache local e começa a consumir os segmentos com base nos URLs do MPD. • O tempo é controlado pelo cliente MPD e DASH: os segmentos não têm tempo atribuído.[00127] Specific reception for ROUTE has been documented as follows: • The LSID describes the IP/port combination and different LCT sessions. • Different media components represented in segmented ISO BMFF files are associated with and uniquely assigned to an IP/port/TSI combination. • The service is described by an MPD URL. • The ROUTE receiver retrieves objects for a channel component/service. • Upon reception of objects, the ROUTE receiver assigns a URL to each object using FDT/EFDT (or possibly entity mode). • DASH client receives MPD URL, gets it from local cache and starts consuming segments based on MPD URLs. • Timing is controlled by the MPD and DASH client: segments have no assigned time.

[00128] Numa abordagem alternativa, podem-se por: • A sinalização de camada inferior proporciona informação suficiente, a fim de iniciar o serviço sem o MPD. • Se unidifusão é adicionada ou se seleção mais rica é necessária, e MPD é consultado, o MPD pode ainda ser um MPD unificada, mas tratado como não é necessário para a inicialização. A MPD pode mesmo ser configurada de tal modo que para a transmissão somente, nenhum MPD é usado, e também, a necessidade de URL de link não é necessária. Deste modo, estas técnicas podem evitar a necessidade do FDT, EFDT, ou outros meios para se ligar URLs para objetos.[00128] In an alternative approach, one could: • Lower layer signaling provides sufficient information in order to initiate service without the MPD. • If unicast is added or if richer selection is required, and MPD is queried, the MPD may still be a unified MPD, but treated as not required for initialization. The MPD can even be configured in such a way that for transmission only, no MPD is used, and also, the need for link URL is not necessary. In this way, these techniques can avoid the need for FDT, EFDT, or other means of linking URLs to objects.

[00129] Esta revelação descreve um design semelhante ao exemplo desta abordagem, o que pode proporcionar vantagens para a eficiência de largura de banda, o arranque inicial, a simplicidade, robustez, razões de capacidade de extensão e complexidade, sem desvantagens significativas. A fim de manter a compatibilidade com os serviços existentes e abordar diferentes casos de uso, a seguinte abordagem pode ser considerada: • O serviço de sinalização fornece uma indicação sobre qual das seguintes abordagens podem ser tomadas: 1. O receptor precisa do MPD mesmo para o arranque, ou seja, o cliente DASH não deve ser iniciado e a inicialização do serviço não deve ser feito sem o MPD. Isso basicamente replicar a abordagem atual. 2. O prestador de serviços fornece sinalização suficiente para que a inicialização sem o MPD é possível e permitido, mas o MPD também é fornecido e descreve ofertas de conteúdo mais rico e alternativas. 3. O fornecedor de serviços não fornece um MPD de todo, o serviço está completamente descrita pela sinalização da camada inferior, e nenhuma informação enriquecida é ativado. Isso impediria um serviço de transmissão/banda larga híbrido. • Exemplos de serviços para os diferentes casos: 1. serviço criptografado com informações detalhadas no MPD, usando a primeira abordagem. 2. Um serviço Livre A/V com componentes de unidifusão que podem enriquecer serviço, usando a segunda abordagem. 3. Serviço Simples livre ao ar A/V A sem necessidade de MPD, usando a terceira abordagem.[00129] This disclosure describes a design similar to the example of this approach, which can provide advantages for bandwidth efficiency, initial start-up, simplicity, robustness, extendability ratios and complexity, without significant disadvantages. In order to maintain compatibility with existing services and address different use cases, the following approach can be considered: • The signaling service provides an indication as to which of the following approaches can be taken: 1. The receiver needs the MPD even to startup, that is, the DASH client must not be started and the service initialization must not be done without the MPD. This basically replicates the current approach. 2. The service provider provides sufficient signage so that startup without the MPD is possible and permitted, but the MPD is also provided and describes richer content offerings and alternatives. 3. The service provider does not provide an MPD at all, the service is completely described by the lower layer signaling, and no enriched information is activated. This would preclude a hybrid broadcast/broadband service. • Examples of services for different cases: 1. encrypted service with detailed information in the MPD, using the first approach. 2. A Free A/V service with unicast components that can enrich service, using the second approach. 3. Simple free-to-air A/V A service with no MPD required, using the third approach.

[00130] Os seguintes problemas podem ocorrer com a abordagem de cima para baixo que distribui o MPD como o ponto de entrada: • Formatos DASH mídia estão distribuídos por uma distribuição de Broadcast. • Para o arranque da sessão, vários objetos de dados (sinalização da camada inferior, descrição de sessão, FDT/EFDT/métodos equivalentes, MPD, IS e pelo menos uma parte do segmento de mídia) precisam ser recebidos, a fim de aceder aleatoriamente os dados e para programar a reprodução. • A seleção de mídia e o controle de tempo estão no MPD, por isso é necessário para receber o MPD antes do arranque e para receber os metadados para identificar o MPD. • Outra questão é que o MPD, se inalterado, precisa ser gerado no remetente de uma forma que o sincronismo no receptor pode ser previsto. • Outra questão é que o MPD precisa ser enviado com cada ponto de acesso aleatório em todos os componentes, a fim de acessar o vídeo ou áudio rapidamente. • No entanto, outra questão é que o FDT ou EFDT é necessária, a fim de ser capaz de mapear as URLs. • Finalmente, o MPD e os metadados são tipicamente formatados de acordo com XML, e do MPD unificada descreve todo o serviço, incluindo todos os componentes, bem como todos os dados entregues em unidifusão/banda larga. Isso pode tornar o MPD desnecessariamente grande, enquanto no início apenas a informação de transmissão pode ser necessária.[00130] The following problems may occur with the top-down approach that distributes the MPD as the entry point: • DASH media formats are distributed by a Broadcast distribution. • For session initiation, several data objects (lower layer signaling, session description, FDT/EFDT/equivalent methods, MPD, IS and at least a part of the media segment) need to be received in order to access randomly data and to program playback. • Media selection and timing control are in the MPD, so it is necessary to receive the MPD before booting and to receive the metadata to identify the MPD. • Another issue is that the MPD, if unchanged, needs to be generated at the sender in a way that timing at the receiver can be predicted. • Another issue is that MPD needs to be shipped with each random access point on all components in order to access video or audio quickly. • However, another issue is that the FDT or EFDT is required in order to be able to map the URLs. • Finally, the MPD and the metadata are typically formatted according to XML, and the unified MPD describes the entire service, including all components as well as all data delivered unicast/broadband. This may make the MPD unnecessarily large, while at first only transmission information may be needed.

[00131] As técnicas da presente revelação podem superar qualquer ou todos os problemas acima discutidos.[00131] The techniques of the present disclosure can overcome any or all of the problems discussed above.

[00132] Por exemplo, um dispositivo de recepção (por exemplo, o dispositivo de cliente 40) pode ser configurado para operar (isto é, receber, dados multimídia processo, e decodificar) sem o EFDT, FDT, e/ou MPD num modo unidirecional/transmissão. Em particular, o dispositivo de cliente 40 pode receber versões alternativas da informação a partir destas estruturas de dados que de outro modo seriam necessários para o arranque e/ou operação permanente por outros meios.[00132] For example, a receiving device (e.g., client device 40) may be configured to operate (i.e., receive, process, and decode multimedia data) without the EFDT, FDT, and/or MPD in a mode unidirectional/transmission. In particular, client device 40 may receive alternative versions of information from these data structures that would otherwise be required for startup and/or ongoing operation by other means.

[00133] A figura 9 é um diagrama conceitual ilustrando campos de cabeçalho LCT 320 em conformidade com a RFC 5651, que pode ser utilizado para transportar dados de acordo com as técnicas desta revelação. Em particular, cabeçalho LCT 320 inclui campo de versão 322, sinalizador de controle do congestionamento 324, campo de indicação específicos de protocolo (PSI) 326, sinalizador de identificador de sessão de transporte (S) 328, sinalizador de identificador de objeto de transporte (O) 330, sinalizador de meia-palavra (H) 332, campo reservado (RES) 334, sinalizador de sessão próxima (A) 336, sinalizador de próximo objeto (B) 338, campo de comprimento de cabeçalho LCT (HDR LEN) 340, campo de ponto de código 342, informação de controle de congestionamento 344, identificador de sessão de transporte 346, identificadores de objetos de transporte 348, e campo de extensões de cabeçalho 350.[00133] Figure 9 is a conceptual diagram illustrating LCT 320 header fields in accordance with RFC 5651, which can be used to transport data in accordance with the techniques of this disclosure. In particular, LCT header 320 includes version field 322, congestion control flag 324, protocol specific indication (PSI) field 326, transport session identifier (S) flag 328, transport object identifier flag ( O) 330, half-word flag (H) 332, reserved field (RES) 334, next session flag (A) 336, next object flag (B) 338, LCT header length field (HDR LEN) 340 , code point field 342 , congestion control information 344 , transport session identifier 346 , transport object identifiers 348 , and header extensions field 350 .

[00134] Os valores do campo de versão 322, sinalizador de controle do congestionamento 324, campo de indicação específicos de protocolo (PSI) 326, sinalizador de identificador de sessão de transporte (S) 328, sinalizador de identificador de objeto de transporte (O) 330, sinalizador meia-palavra (H) 332, campo reservado (RES) 334, sinalizador de sessão próxima (A) 336, sinalizador de objeto próximo (B) 338, campo de comprimento de cabeçalho LCT (HDR LEN) 340, campo ponto de código 342, a informação de controle do congestionamento 344, identificador de sessão de transporte 346, e identificador de objeto de transporte 348 pode ser definido de acordo com a RFC 5651, e de acordo com as técnicas desta revelação, como discutido abaixo. Campo de extensão de cabeçalho 350 pode ser ajustado de acordo com as técnicas desta revelação.[00134] The values of version field 322, congestion control flag 324, protocol specific indication field (PSI) 326, transport session identifier flag (S) 328, transport object identifier flag (O ) 330, half-word flag (H) 332, reserved field (RES) 334, close session flag (A) 336, close object flag (B) 338, LCT header length field (HDR LEN) 340, field code point 342, congestion control information 344, transport session identifier 346, and transport object identifier 348 may be defined in accordance with RFC 5651, and in accordance with the techniques of this disclosure, as discussed below. Header extension field 350 may be adjusted in accordance with the techniques of this disclosure.

[00135] As seguintes funcionalidades estão disponíveis e podem, eventualmente, ser utilizado, a fim de apoiar a entrega de informação que é estabelecido em contrário no MPD e/ou EFDT. Os campos que podem ser utilizados para o transporte de dados de acordo com as técnicas desta revelação são marcados em itálico abaixo: ■ LSID (como definido na especificação de ROUTE do projeto de ATSC 3,0) o Uso do descritor de conteúdo na LSID para sinalizar a atribuição de propriedades do componente para transportar sessão, a fim de selecionar a sessão de transporte para ser entregue à camada mídia. o Uso de cessão ponto de código ■ ROUTE/LCT campos de cabeçalho (ver RFC 5651 e figura 9). A Informação de Controle de Congestionamento (CCI) 344: 32, 64, 96 ou 128 bits. Usado para transportar informações de controle de congestionamento. Por exemplo, a informação de controle de congestionamento pode incluir números de camadas, os números dos canais lógicos, e os números de sequência. Este campo é opaco para o propósito desta especificação, por isso, pode ser utilizado de uma forma arbitrária. o TSI: Identificador de Sessão de Transporte (TSI) 346: 0, 16, 32, ou 48 bits. A TSI identifica exclusivamente uma sessão entre todas as sessões de um determinado remetente. A TSI tem como escopo pelo endereço IP do remetente, e, portanto, o endereço IP do remetente e da TSI juntas, identificam exclusivamente a sessão. Embora a TSI em conjunto com o endereço IP do remetente sempre identifica exclusivamente uma sessão, ou não o TSI está incluído no cabeçalho LCT depende do que é usado como o valor TSI. Se o transporte subjacente é UDP, então o número da porta de origem UDP de 16 bits pode servir como o TSI para a sessão. O identificador de transporte de objeto (TOI) 348: 0, 16, 32, 48, 64, 80, 96, ou 112 bits. Este campo indica para qual objeto dentro da sessão deste pacote pertence. Por exemplo, um remetente pode enviar um número de arquivos na mesma sessão, usando TOI = 0 para o primeiro arquivo, T0I = 1 para o segundo, etc. Como outro exemplo, o TOI pode ser um identificador global único do objeto que está a ser transmitido a partir de várias remetentes simultaneamente, e o valor TOI pode ser a produção de uma função hash aplicada ao objeto. O Point Code 342: 8 bits estão disponíveis para sinalizar diferentes propriedades do objeto contido, bem como a relação com o pacote atual. Um identificador opaco que é passado para a decodificação de pacotes carga útil para transmitir informações sobre o codec sendo usado para a carga do pacote. O mapeamento entre o ponto de código e o codec real é definido em uma base por sessão e comunicado fora de faixa, como parte das informações sessão descrição. O uso do campo CP é semelhante ao do campo de tipo de carga útil (PT) em cabeçalhos RTF como descrito em [RFC3550]. O Sinalizadores de cabeçalho específico no cabeçalho LCT ■ PSI 326: O uso destes bits, se qualquer, é específico para cada instanciação protocolo que utiliza o bloco de construção LCT. Se não houver a utilização de protocolos específicos de instanciação desses bits é definido, então um remetente deve ajustar em zero, e um receptor deve ignorar esses bits. ■ RES 334: propriedade da LCT, então não utilizado correntemente cabeçalho de extensão ROUTE/LCT (ver RFC 5651 e figura 9 Erro! fonte de referência não encontrada). O Extensões de cabeçalho 350 podem ser usadas em LCT para acomodar campos de cabeçalho opcionais que não são sempre utilizados ou têm tamanho variável. Exemplos do uso de extensões de cabeçalho incluem: ■ versões de tamanho prolongado de cabeçalho campos já existentes. ■ Informações de autenticação de remetente e receptor. ■ Transmissão de informação de tempo. ■ Segmento de inicialização (Header Filme) da ISO BMFF (ver ISO/IEC 14496-12) o Os metadados para uma apresentação é armazenada na caixa único filme que ocorre no nível superior de um arquivo. O cabeçalho do filme permite adicionar informação adicional que está relacionado com os aspectos específicos de mídia do componente, por exemplo: ■ cabeçalho de mídia, informações gerais sobre a mídia ■ manipulador, declara o tipo de mídia (manipulador) ■ recipiente de informações de mídia • Fora de ROUTE, LCT e ISO BMFF o A informação sobre a camada física (FIT) o Informações na camada de apresentação/aplicativo que executa o serviço.[00135] The following functionalities are available and may eventually be used in order to support the delivery of information that is otherwise established in the MPD and/or EFDT. Fields that can be used to transport data in accordance with the techniques of this disclosure are marked in italics below: ■ LSID (as defined in the ROUTE specification of the ATSC 3.0 project) o Use of the content descriptor in the LSID to signal assignment of component properties to transport session in order to select the transport session to be delivered to the media layer. o Use of code point assignment ■ ROUTE/LCT header fields (see RFC 5651 and Figure 9). Congestion Control Information (CCI) 344: 32, 64, 96 or 128 bits. Used to carry congestion control information. For example, congestion control information may include layer numbers, logical channel numbers, and sequence numbers. This field is opaque for the purposes of this specification, so it can be used in an arbitrary way. o TSI: Transport Session Identifier (TSI) 346: 0, 16, 32, or 48 bits. TSI uniquely identifies a session among all sessions for a given sender. The TSI is scoped by the sender's IP address, and therefore the sender's IP address and the TSI together uniquely identify the session. Although the TSI in conjunction with the sender's IP address always uniquely identifies a session, whether or not the TSI is included in the LCT header depends on what is used as the TSI value. If the underlying transport is UDP, then the 16-bit UDP source port number can serve as the TSI for the session. The object transport identifier (TOI) 348: 0, 16, 32, 48, 64, 80, 96, or 112 bits. This field indicates which object within the session this package belongs to. For example, a sender may send a number of files in the same session, using TOI = 0 for the first file, T0I = 1 for the second, etc. As another example, the TOI may be a globally unique identifier of the object being transmitted from multiple senders simultaneously, and the TOI value may be the output of a hash function applied to the object. Point Code 342: 8 bits are available to signal different properties of the contained object, as well as the relationship to the current package. An opaque identifier that is passed to the packet decoding payload to convey information about the codec being used for the packet payload. The mapping between the code point and the actual codec is defined on a per-session basis and communicated out-of-band as part of the session description information. The use of the CP field is similar to that of the payload type (PT) field in RTF headers as described in [RFC3550]. O Specific header flags in the LCT header ■ PSI 326: The use of these bits, if any, is specific to each protocol instantiation that uses the LCT building block. If no protocol-specific instantiation of these bits is defined, then a sender must set to zero, and a receiver must ignore these bits. ■ RES 334: property of LCT, so not currently used ROUTE/LCT extension header (see RFC 5651 and figure 9 Error! reference source not found). Header Extensions 350 can be used in LCT to accommodate optional header fields that are not always used or are variable in size. Examples of the use of header extensions include: ■ Extended-length versions of existing header fields. ■ Sender and receiver authentication information. ■ Transmission of time information. ■ Initialization segment (Movie Header) of ISO BMFF (see ISO/IEC 14496-12) o The metadata for a presentation is stored in the single movie box that occurs at the top level of a file. The movie header allows you to add additional information that is related to the media-specific aspects of the component, for example: ■ media header, general information about the media ■ handler, declares the media type (handler) ■ media information container • Outside of ROUTE, LCT and ISO BMFF o Information about the physical layer (FIT) o Information about the presentation/application layer that executes the service.

[00136] As funcionalidades relevantes da MPD estão resumidos a seguir, e como tratá-los de acordo com as técnicas desta revelação são discutidos em maior detalhe abaixo.[00136] The relevant features of the MPD are summarized below, and how to treat them in accordance with the techniques of this disclosure are discussed in greater detail below.

[00137] Tempos de Disponibilidade e Ancoragem de Tempo de Apresentação: O tempo de disponibilidade é sinalizado de modo que o tempo de disponibilidade do objeto ou a parte MDE do objeto é sinalizado no cabeçalho. A ancoragem tempo de apresentação é tal que quando os dados são disponibilizados para o cliente ISO BMFF, o cliente começa a decodificação e realizando reprodução imediatamente. Os detalhes do sincronismo são discutidos abaixo.[00137] Availability Times and Presentation Time Anchoring: Availability time is signaled so that the availability time of the object or the MDE part of the object is signaled in the header. The presentation time anchoring is such that when the ISO data is made available to the BMFF client, the client begins decoding and performing playback immediately. Timing details are discussed below.

[00138] Tipo de perfil Apresentação, estático, dinâmico, etc.: Esses parâmetros não têm que ser definidos para a transmissão, mas os dados podem seguir certas regras. Um perfil pode ser definido. O tipo é considerado estático. O perfil detalhado e definição formato de mídia são fornecidos abaixo.[00138] Profile type Presentation, static, dynamic, etc.: These parameters do not have to be defined for transmission, but the data can follow certain rules. A profile can be defined. The type is considered static. The detailed profile and media format definition are provided below.

[00139] Descrições de largura de banda e armazenamento: Estes parâmetros não são relevantes para a distribuição de transmissão, como a temporização é determinada pela chegada dos dados. No entanto, a fim de iniciar um tempo mínimo de armazenamento curto, este aspecto deve ser considerado. Esta questão é discutida abaixo.[00139] Bandwidth and storage descriptions: These parameters are not relevant to transmission distribution, as the timing is determined by the arrival of the data. However, in order to achieve a short minimum storage time, this aspect must be considered. This issue is discussed below.

[00140] Profundidade de armazenamento de mudança de tempo: Este parâmetro não é relevante para a transmissão, como o armazenamento de mudança de tempo é determinado pela informação de recepção. No entanto, pode- se considerar que existem algumas instruções do remetente sobre quanto tempo os dados devem ser armazenados no dispositivo de cliente (isto é, o dispositivo receptor).[00140] Time shift storage depth: This parameter is not relevant for transmission, as time shift storage is determined by the reception information. However, it can be considered that there are some instructions from the sender about how long the data should be stored on the client device (i.e., the receiving device).

[00141] Informação de reinicialização e emenda usando Períodos: Para isso, a sinalização pode ser necessária. Um período muda o segmento de inicialização e redefine a linha do tempo. É necessário que esta informação é transmitida e o reprodução do Período de iniciar relativa aos dados anterior está programada corretamente. Os detalhes sobre como isso pode ser alcançado são fornecidos abaixo.[00141] Reset and splice information using Periods: For this, signaling may be necessary. A period changes the startup segment and resets the timeline. It is necessary that this information is transmitted and the playback of the Start Period relative to the previous data is programmed correctly. Details on how this can be achieved are provided below.

[00142] Conjunto de Adaptação e Metadados de Representação para seleção/rejeição: Para distribuição baseado na ROUTE, a seleção de Adaptação Set e Representações precisa acontecer em nível de sessão de transporte LCT. Uma vez que uma sessão de transporte é selecionada, estes dados são transmitidos para decodificação e processamento para a camada de ISO BMFF. A camada ISO BMFF, com base nas informações no segmento de inicialização ainda pode escolher ou rejeitar ou filtrar alguns dados, mas isso não é relevante para a discussão aqui. Para selecionar a sessão adequada, as informações no LSID são usadas. Este assunto é discutido em maiores detalhes abaixo.[00142] Adaptation Set and Representation Metadata for selection/rejection: For ROUTE-based distribution, selection of Adaptation Set and Representations needs to happen at the LCT transport session level. Once a transport session is selected, this data is transmitted for decoding and processing to the ISO BMFF layer. The ISO BMFF layer, based on the information in the initialization segment may still choose to reject or filter some data, but this is not relevant to the discussion here. To select the appropriate session, the information in the LSID is used. This subject is discussed in greater detail below.

[00143] Relação de Representações (Comutável, dependência, etc.) e sem emenda Informações de comutação: Na maioria das aplicações, apenas uma única representação por Adaptação Set é distribuído em difusão. No entanto, deve haver o caso de múltiplas representações serem transmitidas, em seguida, os aspectos individuais de cada Representação pode ser fornecida na LSID como descrito abaixo. Se for necessário alternar sem interrupção através das diferentes representações, este exigira, então, o MPD, mas apenas quando se realiza a comutação de Representação, e informações necessárias para a comutação contínua nas diferentes representações também podem ser assinalado no segmento de inicialização. Em certos casos, por exemplo, quando se utiliza codificação em camadas, esta informação é também fornecida no segmento de inicialização. Dependência de sessões LSID é sinalizada na LSID, e detalhes adicionais estão descritos abaixo.[00143] Relationship of Representations (Switchable, Dependency, etc.) and Seamless Switching Information: In most applications, only a single representation per Adaptation Set is distributed in broadcast. However, should there be a case where multiple representations are transmitted, then the individual aspects of each representation can be provided in the LSID as described below. If it is necessary to switch seamlessly through the different representations, this will then require the MPD, but only when performing the Representation switching, and information necessary for continuous switching in the different representations can also be signaled in the initialization segment. In certain cases, for example when layered coding is used, this information is also provided in the initialization segment. Dependency on LSID sessions is signaled in the LSID, and additional details are described below.

[00144] Deslocamento de Tempo de Apresentação: O deslocamento tempo de apresentação sinaliza o primeiro tempo de apresentação da Representação no período, ou seja, ele fornece uma âncora. Esta informação deve ser replicada usando informações nos cabeçalhos ROTA. Este assunto é discutido em maiores detalhes abaixo.[00144] Presentation Time Offset: The presentation time offset signals the first presentation time of the Representation in the period, that is, it provides an anchor. This information must be replicated using information in the ROUTE headers. This subject is discussed in greater detail below.

[00145] Localização e URLs de inicialização e Segmentos de mídia: O MPD descreve a localização e ligação de objetos para estruturas MPD, abordando o seguinte problema. Ele diz qual objeto é (segmento de inicialização, segmento de mídia, outros tipos) e colocar no contexto, por exemplo, a sequência dos segmentos de mídia é descrito e fornecem ao cliente DASH as informações sobre como usar os objetos de dados. Os pontos MPD para URLs e por isso uma ligação entre a informação MPD e os arquivos, o fluxo contínuo de mídia é estabelecida. Além disso, o (E) FDT fornece o mapeamento de TOI a URLs. Esta indicação de relacionamento e tipo deve ser replicada pela entrega ROUTE e para este propósito, o cabeçalho ROUTE é usado e o uso rigoroso do TSI, TOI e cabeçalhos percurso é necessária a fim de cumprir esta finalidade. Também certas ordens de envio podem ser tidas em conta. Outro aspecto que pode ser considerado é como um IS diz respeito aos segmentos de mídia. As restrições e os detalhes são discutidos abaixo.[00145] Location and Initialization URLs and Media Segments: MPD describes the location and binding of objects to MPD structures, addressing the following problem. It tells what object it is (initialization segment, media segment, other types) and put in context, for example, the sequence of the media segments is described and provides the DASH client with information about how to use the data objects. The MPD points to URLs and so a link between the MPD information and the files, the continuous flow of media is established. Additionally, the (E)FDT provides the mapping of TOI to URLs. This relationship and type indication must be replicated by the ROUTE delivery and for this purpose, the ROUTE header is used and strict use of the TSI, TOI and route headers is necessary in order to fulfill this purpose. Also certain shipping orders can be taken into account. Another aspect that can be considered is how an IS relates to media segments. Restrictions and details are discussed below.

[00146] Duração de segmentos de mídia: Em geral, a duração dos segmentos de mídia é usada para calcular os tempos de disponibilidade segmento e com a finalidade de buscar. A duração não é de outra maneira relevante. Assim, em geral, a informação não é necessária para a transmissão.[00146] Duration of media segments: In general, the duration of media segments is used to calculate segment availability times and for search purposes. Duration is otherwise not relevant. Thus, in general, information is not necessary for transmission.

[00147] Informações detalhadas sobre Proteção de Conteúdo: A proteção de conteúdo pode ser assinalada no segmento de inicialização. Se questões complexas estão a ser sinalizado, o MPD pode ser considerado necessário. Mas, geralmente, as informações no segmento de inicialização são consideradas suficientes.[00147] Detailed information about Content Protection: Content protection can be marked in the initialization segment. If complex issues are to be flagged, the MPD may be considered necessary. But generally, the information in the initialization segment is considered sufficient.

[00148] Evento de fluxo de sinalização: Representações podem transportar um fluxo de eventos que podem ter de ser analisado pelo cliente DASH. Se fluxos de eventos são considerados relevantes, eles podem ser sinalizados no descritor de conteúdo LSID. Alternativamente, o MPD pode ser usado para comunicar fluxos de eventos, mas tais fluxos de eventos não são relevantes para o arranque. Detalhes adicionais sobre sinalização fluxos de eventos internos da banda no LSID são discutidos abaixo.[00148] Signaling Flow Event: Representations can carry a flow of events that may have to be analyzed by the DASH client. If event streams are considered relevant, they can be flagged in the LSID content descriptor. Alternatively, MPD can be used to communicate event streams, but such event streams are not relevant to booting. Additional details about signaling in-band event streams in the LSID are discussed below.

[00149] Dados auxiliares - Informação de programa, Métricas: O MPD pode transportar informação que é relevante para certas operações, tais como Informações sobre o Programa, Métricas iniciação coleção ou outros meios. Esta informação não é em tempo real crítico e pode ser fornecido, se necessário em tudo, em uma MPD que é entregue com uma frequência mais lenta ou que é fornecido ao longo de unidifusão.[00149] Auxiliary Data - Program Information, Metrics: The MPD may carry information that is relevant to certain operations, such as Program Information, Metrics initiation collection or other means. This information is not real-time critical and can be provided, if necessary at all, on an MPD that is delivered at a slower frequency or that is provided over unicast.

[00150] Os aspectos seguintes são considerados para o estabelecimento de um calendário e armazenamento de modelo: • Cada pacote tem um tempo de transmissão alvo (TTT) semelhante ao que é definido no RFC 2250 para a entrega à base de RTP de MPEG-2 TS. O tempo de transmissão de destino pode: o ser informações sobre sugestão de remetente apenas, ou O ser sinalizado no cabeçalho do pacote LCT como marcação de tempo NTP (o meio 32 bits) de controle do congestionamento ou como relógio de 90 kHz semelhante a MPEG-2 TS ou como qualquer outro relógio com a escala de tempo definido no LSID, por exemplo, o relógio do meio contido. ■ Se estiver presente e conhecida no receptor, a TTT fornece informação sobre quando exatamente para libertar os dados para a camada seguinte, ou seja, para a camada de ISO BMFF. ■ Supõe-se que o manipulador ISO BMFF inicia decodificação imediatamente e processa os dados instantaneamente, uma vez que é liberado a partir do nível ROUTE. ■ Diferentes maneiras são consideradas sobre como sinalizar o tempo para o receptor quando ele pode entregar os dados: o Um cabeçalho de extensão no primeiro pacote do grupo de RAP (a IS tipicamente) e o primeiro pacote dos sinais de segmento de mídia quanto tempo os dados precisam ser segurar no receptor ROUTE até que seja liberado para o próximo nível. Este tempo é chamado o tempo de libertação (RT). RT está na mesma escala de tempo que a TTT e pode ser comparado com selos de tempo TTT (não o tempo real). Com o aumento da TTT a RT não deve diminuir. Se o tempo de RT no cabeçalho extensão excede o maior tempo TTT da corrente objeto/segmento, em seguida, os dados contidos neste pacote devem ser segurar até que o tempo TTT é atingido no segmento seguinte ou qualquer segmento futuro. Especificamente o receptor pode atuar como segue: ■ Se um pacote é recebido com um tempo de RT, em seguida, esses dados podem ser segurar até que um pacote é recebido com TTT que excede RT. ■ Se um pacote é recebido sem uma hora temperatura ambiente, em seguida, os dados de objetos contidos podem ser liberados em conjunto com os dados anteriores, onde “anteriores” é a ordem de objetos em aumentar iniciar números TOI offset e crescentes. Se a TTT está em utilização e o receptor observa instabilidade significativa entre a TTT e o tempo real de recepção, esta instabilidade deve ser compensada, a fim de evitar fluxos secundários de armazenamento. ■ Por exemplo, um dispositivo pode adicionar algum atraso adicional ou transmitir infraestrutura acrescenta alguma demora adicional na partida. o Opção 2: Neste caso, o tempo de parede relógio absoluta é utilizada para programar decodificação. O objeto é atribuído um tempo relógio de parede em que o objeto está a ser movido para o motor ISO BMFF. Este caso é mais relevante quando sincronizado reprodução entre diferentes usuários é importante. Com aumento do tempo de relógio de parede, o RT deve aumentar. Especificamente o receptor está prevista para atuar como a seguir: ■ Se um pacote é recebido com um tempo de RT, em seguida, estes dados podem ser retidos até que o tempo de relógio de parede documentado em RT é atingido. ■ Se um pacote é recebido sem uma hora temperatura ambiente, em seguida, os dados de objetos contidos podem ser liberados em conjunto com os dados anteriores, onde anterior é da ordem dos objetos que é no aumento da compensação inicial e um número crescente de TOI. o Opção 3: Um bocado de cabeçalho no cabeçalho ROUTE é ajustado para 10, a fim de sinalizar que os dados contidos ainda não pode ser liberado para o próximo nível. Só se o bit não for definido, definido (ou seja, igual a 1), os dados podem ser entregues e empurradas para frente. Se o último pacote do objeto (indicado pelo sinalizador B a ser definido no cabeçalho LCT) ainda tem o bit ajustado para 10, então este pode ser liberado apenas quando o objeto está completo. No entanto, note que um objeto completo pode sempre ser entregue. Em alternativa, este bit de cabeçalho é obrigatório para ser igual a 1 para o último pacote de cada objeto. • Se o TTT está em uso e o receptor observa instabilidade significativa entre a TTT e a hora de recepção real, esta instabilidade deve ser compensada para evitar armazenamento de fluxo secundário. o Por exemplo, um dispositivo pode adicionar algum atraso adicional ou transmitir infra-estrutura adiciona algum adicional arranque demora.[00150] The following aspects are considered for establishing a timing and storage model: • Each packet has a target transmission time (TTT) similar to what is defined in RFC 2250 for MPEG-2 RTP-based delivery TS. The destination transmission time can: o be sender suggestion information only, or o be signaled in the LCT packet header as an NTP timestamp (the 32-bit means) of congestion control or as an MPEG-like 90 kHz clock -2 TS or like any other clock with the time scale defined in the LSID, for example the contained medium clock. ■ If present and known at the receiver, the TTT provides information about when exactly to release the data to the next layer, i.e. to the ISO BMFF layer. ■ It is assumed that the ISO BMFF handler starts decoding immediately and processes the data instantly once it is released from the ROUTE level. ■ Different ways are considered on how to signal the time to the receiver when it can deliver the data: o An extension header in the first packet of the RAP group (the IS typically) and the first packet of the media segment signals how long the Data needs to be held in the ROUTE receiver until it is released to the next level. This time is called the release time (RT). RT is on the same time scale as TTT and can be compared with TTT timestamps (not real time). As TTT increases, RT should not decrease. If the RT time in the extension header exceeds the highest TTT time of the current object/segment, then the data contained in this packet MUST be held until the TTT time is reached in the next segment or any future segment. Specifically the receiver can act as follows: ■ If a packet is received with a time of RT, then this data can be held until a packet is received with TTT that exceeds RT. ■ If a packet is received without an ambient temperature time, then the contained object data may be released together with the previous data, where “previous” is the order of objects in increasing starting TOI offset and increasing numbers. If TTT is in use and the receiver observes significant instability between TTT and actual reception time, this instability must be compensated in order to avoid storage secondary flows. ■ For example, a device may add some additional delay or transmit infrastructure adds some additional delay at departure. o Option 2: In this case, the absolute clock wall time is used to schedule decoding. The object is assigned a wall clock time at which the object is to be moved to the ISO BMFF engine. This case is most relevant when synchronized playback between different users is important. With increasing wall clock time, RT should increase. Specifically the receiver is expected to act as follows: ■ If a packet is received with an RT time, then this data may be retained until the wall clock time documented in RT is reached. ■ If a packet is received without an ambient temperature time, then the contained object data may be released together with the previous data, where previous is the order of the objects which is in increasing initial offset and an increasing number of TOI . o Option 3: A header bit in the ROUTE header is set to 10 in order to signal that the contained data cannot yet be flushed to the next level. Only if the bit is not set, set (i.e. equal to 1), can data be delivered and pushed forward. If the last packet of the object (indicated by the B flag to be set in the LCT header) still has the bit set to 10, then it can be released only when the object is complete. However, note that a complete object can always be delivered. Alternatively, this header bit is required to be equal to 1 for the last packet of each object. • If TTT is in use and the receiver observes significant instability between the TTT and actual reception time, this instability must be compensated to avoid sidestream storage. o For example, a device may add some additional delay or transmit infrastructure adds some additional startup delay.

[00151] Três tipos diferentes de recepção são considerados: 1. Recepção com base em MDE: Em um primeiro caso, a reprodução no receptor está acontecendo tão rapidamente quanto possível com base em prefixos de arquivos ISO BMFF. 2. Em um segundo caso, apenas os segmentos completos deve ser liberado para o próximo nível. Os segmentos completos ou são solicitadas pelo cliente DASH ou eles são liberados de acordo com a RT e TTT ou parede- relógio comparação. Tipicamente, o receptor ROUTE faz com que o segmento disponível com base na informação de RT. O cliente DASH envia solicitações com base nas informações MPD. O conteúdo deve ser criado e entregue de tal forma que a hora de início disponibilidade segmento mais cedo do que o tempo de liberação é. 3. Ancoragem Wall-clock: Em um terceiro caso, a apresentação dos dados é retida por algum tempo, a fim de permitir a sincronização com outros meios, por exemplo, entregues fora do sistema DASH. O RAP deve ser liberado de acordo com esses dados. No entanto, o princípio em todos os três casos permanece o mesmo; pode ser apenas que as unidades de dados que está sendo lançados são ou MDEs ou segmentos completos.[00151] Three different types of reception are considered: 1. MDE-based reception: In a first case, playback at the receiver is happening as quickly as possible based on ISO BMFF file prefixes. 2. In a second case, only the complete segments should be released to the next level. The complete segments are either requested by the DASH client or they are released according to the RT and TTT or wall-clock comparison. Typically, the ROUTE receiver makes the segment available based on the RT information. The DASH client sends requests based on the MPD information. Content must be created and delivered in such a way that the segment availability start time is earlier than the release time. 3. Wall-clock anchoring: In a third case, the data presentation is retained for some time in order to allow synchronization with other media, for example, delivered outside the DASH system. The RAP must be released according to this data. However, the principle in all three cases remains the same; It may just be that the data units being posted are either MDEs or complete segments.

[00152] A figura 10 é um diagrama conceitual que ilustra várias opções para sinalização quando um prefixo de um objeto pode ser liberado para a próxima camada de decodificação. As seguintes opções exemplares, correspondendo a algumas das várias opções discutidas em maior detalhe a seguir, são explicadas resumidamente abaixo e ilustrado na figura 10: 1. Primeira Opção Exemplar 360: Para este exemplo, a figura 10 ilustra uma série de pacotes incluindo um pacote RAP 366 e os pacotes 368A, 368B e 374. Cada um destes pacotes contém um respectivo alvo Tempo de Transmissão (TTT) que, basicamente, corresponde ao tempo de decodificação no nível do sistema. Neste exemplo, cada pacote de RAP 366 e os pacotes de 368 A, 368B contém TTT1 362, enquanto pacote 374 inclui TTT2 370. A informação TTT é utilizada pelo programador para programar a entrega. Além disso, o pacote RAP 366 inclui um tempo de libertação (RT) 364 no mesmo domínio que as informações TTT, e TA 364 determinam quando o primeiro pacote do grupo (o segmento de inicialização (IS), tipicamente), ou qualquer outro pacote, pode ser libertada para a camada seguinte para processamento imediato. A RT pode ser adicionado de uma vez por um objeto ou pode ser adicionado várias vezes para um objeto. A RT pode aumentar juntamente com o aumento do tempo de envio dentro de um objeto para libertar objetos de uma forma mais fluindo como forma. Neste exemplo, pacote RAP 366, pacote 368A, e 368B pacote são liberados quando TTT1 <RT 364 <TTT2. 2. Segundo Exemplo 380 Opção: Para este exemplo, a figura 10 ilustra uma série de pacotes incluindo um pacote RAP 384 e os pacotes de 386, 388, 392. O pacote RAP 384 está associada a RT 382. Supõe-se que o pacote RAP 384 é recebida no momento NTPl, pacote 386 for recebido no NTP2, pacote 388 é recebida no NTP3, e pacote 392 for recebido no NTPX. Neste caso, apenas um tempo de liberação no NTP é adicionado para o objeto. Isto é semelhante a um tempo de disponibilidade segmento no MPD, ou seja, é permitido transmitir o objeto, após este tempo. Assim, pacotes RAP 384 podem ser liberados com o tempo 390 quando NTP> = RT 382. O aspecto benéfico é que esta não requer nenhuma sinalização tempo adicional, mas quer o remetente tem de ter atraso de entrega e instabilidade em consideração na determinação deste tempo de libertação em NTP ou o problema existe que qualquer atraso inesperado na entrega causa problemas como quer o objeto não pode ser apresentada em tempo útil (resultando em atrasos inicialização) ou o objeto é recebido adiada de tal forma que a linha do tempo é perdida. A opção é benéfica para o propósito ao usar uma sincronização relógio de parede. 3. Terceiro Exemplo 400 Opção: Para este exemplo, a figura 10 ilustra uma série de pacotes, incluindo pacotes RAP 404 e os pacotes de 406A, 406B, 412. Neste caso, RAP pacote 404 contém um sinalizador de libertação (RF) 402 (ou “manter sinalizador”), que inclui informação indicativa tempo após o qual os dados pode ser liberados para a camada seguinte. Neste exemplo, RF = 0 para RAP de pacotes 404 e os pacotes de 406A, 406B. Deste modo, após o tempo de NTP 410, 404 de pacotes de RAP e pacotes 406 A, 406B pode ser liberado, porque o tempo em tempo de NTP 410 é RF = 1 408 (associada com pacote 412). Esta abordagem é bastante simples, mas pode encontrar um problema, uma vez que não pode permitir que a sinalização através de limites segmento. Não obstante, a opção 400 ainda deve ser tido em conta, uma vez que simplifica a operação do receptor ROUTE.[00152] Figure 10 is a conceptual diagram illustrating various options for signaling when an object prefix can be released to the next decoding layer. The following exemplary options, corresponding to some of the various options discussed in greater detail below, are briefly explained below and illustrated in figure 10: 1. First Exemplary Option 360: For this example, figure 10 illustrates a series of packages including a RAP 366 and packets 368A, 368B and 374. Each of these packets contains a respective target Transmission Time (TTT) which basically corresponds to the decoding time at the system level. In this example, each RAP packet 366 and packets 368A, 368B contains TTT1 362, while packet 374 includes TTT2 370. The TTT information is used by the scheduler to schedule delivery. Additionally, the RAP packet 366 includes a release time (RT) 364 in the same domain as the TTT information, and TA 364 determines when the first packet in the group (the initialization segment (IS), typically), or any other packet , can be released to the next layer for immediate processing. The RT can be added once for an object or can be added multiple times for an object. RT can increase along with increasing shipping time within an object to release objects in a more flowing form. In this example, RAP packet 366, packet 368A, and packet 368B are released when TTT1 <RT 364 <TTT2. 2. Second Example 380 Option: For this example, Figure 10 illustrates a series of packets including a RAP packet 384 and packets 386, 388, 392. The RAP packet 384 is associated with RT 382. It is assumed that the packet RAP 384 is received at NTPl, packet 386 is received at NTP2, packet 388 is received at NTP3, and packet 392 is received at NTPX. In this case, only one NTP release time is added to the object. This is similar to a thread availability time in MPD, i.e. it is allowed to transmit the object after this time. Thus, RAP packets 384 can be released with time 390 when NTP >= RT 382. The beneficial aspect is that this does not require any additional signaling time, but either the sender has to take delivery delay and instability into consideration in determining this time. release in NTP or the problem exists that any unexpected delay in delivery causes problems such as either the object cannot be presented in a timely manner (resulting in initialization delays) or the object is received delayed in such a way that the timeline is lost. The option is beneficial for the purpose when using a wall clock sync. 3. Third Example 400 Option: For this example, Figure 10 illustrates a series of packets, including RAP packets 404 and packets 406A, 406B, 412. In this case, RAP packet 404 contains a release flag (RF) 402 ( or “hold flag”), which includes information indicating the time after which data can be released to the next layer. In this example, RF = 0 for RAP packets 404 and packets 406A, 406B. Thus, after NTP time 410, RAP packets 404 and packets 406 A, 406B can be released, because the time in NTP time 410 is RF = 1 408 (associated with packet 412). This approach is quite simple, but you may encounter a problem as it cannot allow signaling across segment boundaries. Nevertheless, option 400 should still be taken into account, as it simplifies the operation of the ROUTE receiver.

[00153] A figura 11 é um diagrama conceitual que ilustra dois modelos exemplo, para receber e armazenamento de dados recebidos. A unidade de recuperação 52 do dispositivo de cliente 40 pode incluir um ou mais componentes configurados de acordo com qualquer um destes exemplos. No primeiro exemplo de modelo 432, o receptor de saída ROUTE 426 recebe pacotes, tais como pacotes RAP 420 e pacotes 422, 424. receptor ROUTE e memória intermédia de saída iniciados e horários de decodificação e de apresentação com a norma ISO 430. Decodificador de receptor BMFF ROUTE e memória intermédia de saída passam os dados recebidos na forma de uma corrente ISO BMFF para armazenamento ISO BMFF 428. Com base na programação estabelecida pelo armazenamento de receptor e de saída ROUTE 426, ISO BMFF decodificador 430 obtém dados de ISO armazenamento BMFF 428, em seguida, decodifica e apresenta os dados buscados.[00153] Figure 11 is a conceptual diagram that illustrates two example models, for receiving and storing received data. The recovery unit 52 of the client device 40 may include one or more components configured in accordance with any of these examples. In the first example model 432, the ROUTE output receiver 426 receives packets such as RAP packets 420 and packets 422, 424. ROUTE receiver and output buffer initiated and decoding and display times with ISO 430. BMFF ROUTE receiver and output buffer pass the received data in the form of an ISO BMFF stream to ISO BMFF storage 428. Based on the programming established by receiver storage and output ROUTE 426, ISO BMFF decoder 430 obtains data from ISO BMFF storage 428 then decodes and displays the fetched data.

[00154] No segundo exemplo de modelo 452, ROUTE receptor 446 recebe os pacotes, como o pacote de RAP 440 e pacotes 442, 444. Receptor ROUTE armazena os pacotes recebidos na saída ROUTE e armazenamento ISO BMFF 448, e iniciados e horários de decodificação e de apresentação com ISO BMFF decodificador 450. ISO BMFF decodificador 450 obtém dados de saída ROUTE e armazenamento ISO BMFF 448, e decodifica e apresenta os dados buscados.[00154] In the second example of model 452, ROUTE receiver 446 receives the packets, such as RAP packet 440 and packets 442, 444. ROUTE receiver stores the received packets in ROUTE output and ISO BMFF storage 448, and start and decoding times and presentation with ISO BMFF decoder 450. ISO BMFF decoder 450 obtains data from ROUTE output and ISO BMFF 448 storage, and decodes and displays the fetched data.

[00155] Com base na descrição acima, os seguintes aspectos podem ser relevantes: • A disponibilidade de tempo é fornecida, por exemplo, de acordo com uma das três opções da figura 10 acima, por exemplo, uma das opções 360, 380, ou 400. Este é o tempo quando a primeira parte do segmento é liberada para o cliente ISO BMFF. • O tempo de apresentação é tal que a decodificação e renderização são iniciadas instantaneamente no receptor com base nas informações fornecidas. Note-se que isto é apenas um modelo de dados, e o armazenamento entre o receptor e o receptor ROUTE ISO BMFF pode ser compartilhada. Dois exemplos de modelos (432, 452) são mostrados na figura 11. O pacote de RAP (por exemplo, pacote RAP 420 ou RAP pacote 440 pode conter informação no MDE que compensa o período inicial e o desvio de tempo de apresentação, isto é, o início da primeira apresentação no segmento de mídia pode ser instantâneo. • verificação Tampão e atrasos reprodução iniciais pode ser sinalizado por um dos três exemplos de opções (360, 380, 400) acima. • Há casos diferentes que podem ser considerados na seguinte no modo operacional (exemplo de sinalização dos diferentes tipos é fornecido abaixo). Os casos diferentes a serem considerados incluem: o Pacotes de segmentos de mídia regulares são apenas passou para o buffer ISO BMFF sem qualquer programação no receptor ROUTE. O remetente garante que o atraso de reprodução inicial fornece uma reprodução perfeita, sem falta de dados na memória intermédia. Esses pacotes podem conter RTs, bem como para libertação de programação, mas normalmente isto não é necessário uma vez que podem ser liberados imediatamente como a reprodução é programado pela camada de ISO BMFF. Segmentos o Redundante de inicialização são ignorados pelo receptor e são descartados e não serão passados para o decodificador ISO BMFF. Segmentos o Aumentada de inicialização são fornecidos ao BMFF ISO decodificador. O decodificador deve, porém, ser informado de que a mídia é tempo contínuo, e que somente algumas informações não-essenciais alterado. No entanto, caso não exista tal API, em seguida, uma reinicialização pode ser feito e a reprodução pode ser remarcada. o Limite de período de conteúdo: Neste caso, o IS devem ser encaminhados e uma nova programação completa é aplicada. Note-se que isto pode resultar em casos para os quais o armazenamento ISO BMFF com algumas amostras é corado ou não há dados disponíveis para um pequeno tempo que precisa ser tratada pelo decodificador. Isso é idêntico às operações regulares DASH. • Observe que a operação acima pode ser possível porque o remetente deve cumprir os requisitos de envio discutidos abaixo em maior detalhe.[00155] Based on the above description, the following aspects may be relevant: • Time availability is provided, for example, according to one of the three options in figure 10 above, for example, one of options 360, 380, or 400. This is the time when the first part of the segment is released to the ISO BMFF client. • The presentation time is such that decoding and rendering are initiated instantly at the receiver based on the information provided. Note that this is just a data model, and storage between the ROUTE ISO BMFF receiver and the receiver may be shared. Two example models (432, 452) are shown in Figure 11. The RAP packet (e.g., RAP packet 420 or RAP packet 440 may contain information in the MDE that compensates for the initial period and presentation time deviation, i.e. , the start of the first presentation in the media segment can be instantaneous. • Buffer check and initial playback delays can be signaled by one of the three example options (360, 380, 400) above. • There are different cases that can be considered in the following. in operational mode (example signaling of the different types is given below). Different cases to consider include: o Regular media segment packets are just passed to the ISO BMFF buffer without any programming in the receiver ROUTE. Initial playback delay provides perfect playback without missing data in the buffer. These packets can contain RTs as well for release scheduling, but normally this is not necessary as they can be released immediately as playback is scheduled by the playback layer. of ISO BMFF. Boot Redundant segments are ignored by the receiver and are discarded and will not be passed to the ISO BMFF decoder. o Augmented boot segments are provided to the BMFF ISO decoder. The decoder must, however, be informed that the media is continuous time, and that only some non-essential information is changed. However, if there is no such API, then a reset can be done and playback can be rescheduled. o Content period limit: In this case, the IS must be forwarded and a new complete schedule is applied. Note that this may result in cases for which the ISO BMFF store with some samples is colored or there is no data available for a small time that needs to be handled by the decoder. This is identical to regular DASH operations. • Please note that the above operation may be possible because the sender must comply with the shipping requirements discussed below in greater detail.

[00156] Se o remetente e o receptor estão configurados para utilizar baseada em segmentos fornecimento/recepção, então a informação pode ser adicionada à sinalização de temporização, como discutido abaixo. No entanto, no caso que a recepção baseada em segmentos é realizada com base em uma de entrega baseado em MDE, então o problema é mais complicado, pois o receptor precisa entender como fazer uso da informação de tempo. As seguintes opções devem ser consideradas: • O MPD é disponibilizado a fim de marcar e o sinal do segmento Disponibilidade vezes. • Um atributo é adicionado ao LSID para cada componente que indica o atraso adicional em tempos de tempo de mídia (e TTT) a fim de apoiar recepção baseada em segmento. Tipicamente, tal tempo é a duração máxima do segmento. Note que o tempo não está no tempo relógio de parede, mas em tempo de transmissão, por isso, se uma entrega baseada explosão for feito, então o atraso adicional de entrega segmento podem ser marginalmente mais do que o da recepção baseado em MDE.[00156] If the sender and receiver are configured to use segment-based supply/receive, then information can be added to the timing signaling, as discussed below. However, in the case that segment-based reception is performed based on an MDE-based delivery, then the problem is more complicated, as the receiver needs to understand how to make use of the timing information. The following options should be considered: • The MPD is made available in order to mark and signal the segment Availability times. • An attribute is added to the LSID for each component that indicates the additional delay in media timing (and TTT) times in order to support segment-based reception. Typically, this time is the maximum duration of the segment. Note that the time is not in wall clock time, but in transmission time, so if a burst-based delivery is done, then the additional delay of segment delivery may be marginally more than that of MDE-based reception.

[00157] Se o remetente e o receptor estão configurados para utilizar relógio de parede de ancoragem, isto é, a parede do relógio baseado decodificação, então a informação pode ser adicionada para a informação de sinalização de temporização discutido abaixo. No entanto, pode haver casos em que a entrega com base em MDE é sinalizado, mas o receptor precisa sincronizar a decodificação e reprodução em tempo relógio de parede. As seguintes opções podem ser consideradas: • O MPD é disponibilizado a fim de marcar e o sinal do segmento tempos de disponibilidade, bem como o atraso apresentação sugeridas. • Um atributo é adicionado à LSID para cada componente que indica o mapeamento do TTT ou o tempo de decodificação para a parede do relógio de tempo. • Um cabeçalho de extensão para LCT é criado que fornece essas informações, ou seja, o mapeamento para a parede-relógio reprodução-agendamento.[00157] If the sender and receiver are configured to use wall clock anchoring, that is, wall clock based decoding, then the timing information can be added to the signaling information discussed below. However, there may be cases where delivery based on MDE is signaled, but the receiver needs to synchronize the decoding and playback in wall clock time. The following options can be considered: • The MPD is made available in order to mark and signal the segment availability times, as well as the suggested presentation delay. • An attribute is added to the LSID for each component that indicates the mapping of the TTT or decoding time to the time clock wall. • An extension header for LCT is created that provides this information, i.e. the mapping for the playback-scheduling clock wall.

[00158] De modo a permitir a seleção dos meios entregues numa sessão de transporte LCT com base na informação no LSID, muitos elementos e atributos que são atribuídas a um Conjunto de Adaptação, exceto para as representações, pode ser adicionado à LSID. Especificamente, isso pode incluir qualquer uma ou todas as seguintes informações (para mais detalhes consulte a ISO/IEC 23009-1, cláusula 5.3.4 (Adaptação Set) e 5.3.7 (Atributos Comuns)): • Um identificador usando o elemento @ id. • A associação de grupo usando o atributo @group. • a linguagem como descrito pelo atributo @ lang. • o tipo de componente mídia descrito pelo atributo @contentType. • a relação de aspecto de imagem, tal como descrito pelo atributo @par. • a propriedade papel, como descrito por os elementos de Função. • a propriedade acessibilidade como descrito por os elementos de acessibilidade. • a propriedade ponto de vista, conforme descrito pelos elementos Viewpoint. • a propriedade classificação como descrito por os elementos de classificação. • Informações sobre propriedades segmento (acesso aleatório, etc.): ver experimentos de núcleo SISSI. • atribuir @profiles para o Conjunto de Adaptação. • @largura e @height fornecendo especifica o tamanho apresentação visual horizontal e vertical do tipo de mídia de vídeo em uma grade determinado pelo atributo @sar. • @sar especifica a relação de aspecto de exemplo do tipo de componente de meios de vídeo. • @framerate: especifica a taxa de quadros de saída (ou, no caso de metade da frequência de campo entrelaçado, de saída) do tipo de meios de vídeo. • @audiosamplingRate: taxa máxima de amostragem do tipo de mídia componente de áudio. • @mimeType: especifica o tipo MIME da concatenação do segmento de inicialização, se presente, e todos os segmentos de mídia consecutivos na representação. • @codecs: especifica os codecs presentes dentro da Representação. Os parâmetros de codec podem incluir também o perfil e informações de nível quando aplicável. • @scanType: especifica o tipo de digitalização do material de origem do tipo componente de mídia de vídeo. • FramePacking: especifica informações arranjo de embalagem de quadro do tipo componente de mídia de vídeo. • AudioChannelConfiguration: especifica a configuração do canal de áudio dos meios de comunicação tipo de componente de áudio. • ContentProtection: especifica informações sobre esquemas de proteção de conteúdo utilizados para as representações associadas. • EssentialProperty: especifica informações sobre o elemento que contém que é considerada essencial pela apresentação autor Mídia selecionar este componente. • SupplementalProperty: especifica a informação suplementar sobre o elemento que contém que pode ser usado para o processamento do componente. • InbandEventStream: especifica a presença de um fluxo de eventos dentro da banda nas representações associadas.[00158] In order to allow selection of the media delivered in an LCT transport session based on the information in the LSID, many elements and attributes that are assigned to an Adaptation Set, except for representations, can be added to the LSID. Specifically, this may include any or all of the following information (for further details see ISO/IEC 23009-1, clause 5.3.4 (Set Adaptation) and 5.3.7 (Common Attributes)): • An identifier using the @ element id. • Group membership using the @group attribute. • the language as described by the @lang attribute. • the media component type described by the @contentType attribute. • the image aspect ratio, as described by the @par attribute. • the Role property, as described by the Role elements. • the accessibility property as described by the accessibility elements. • the viewpoint property, as described by the Viewpoint elements. • the classification property as described by the classification elements. • Information about thread properties (random access, etc.): see SISSI core experiments. • assign @profiles to the Adaptation Set. • @width and @height providing specifies the horizontal and vertical visual presentation size of the video media type in a grid determined by the @sar attribute. • @sar specifies the sample aspect ratio of the video media component type. • @framerate: specifies the output (or, in the case of half interlaced field frequency, output) frame rate of the video media type. • @audiosamplingRate: maximum sampling rate of the audio component media type. • @mimeType: Specifies the MIME type of the concatenation of the initialization segment, if present, and all consecutive media segments in the representation. • @codecs: specifies the codecs present within the Representation. Codec parameters may also include profile and level information when applicable. • @scanType: Specifies the scan type of the source material of the video media component type. • FramePacking: Specifies frame packaging arrangement information of the video media component type. • AudioChannelConfiguration: Specifies the audio channel configuration of the media audio component type. • ContentProtection: specifies information about content protection schemes used for the associated representations. • EssentialProperty: specifies information about the element containing this component that is considered essential by the Media presentation author selecting this component. • SupplementalProperty: Specifies supplemental information about the containing element that can be used for component processing. • InbandEventStream: specifies the presence of an in-band event stream in the associated representations.

[00159] Toda esta informação pode ser usada para a seleção no nível da sessão Transportes LCT. Se nenhuma seleção for fornecida, todos os fluxos podem ser encaminhados para o manipulador ISO BMFF para processamento. Esta informação pode ser fornecida para filtragem cedo e seleção no nível de sessão de transporte.[00159] All this information can be used for selection at the LCT Transports session level. If no selection is provided, all streams can be forwarded to the ISO BMFF handler for processing. This information can be provided for early filtering and selection at the transport session level.

[00160] A figura 12 é um diagrama conceitual que ilustra um exemplo conjunto de componentes de um dispositivo receptor 460, incluindo uma seleção e de filtragem da unidade 462, um receptor 464 ROUTE, outros processadores de objeto 466, mídia de processador ISO BMFF 468, e pré-processador ISO BMFF 470. O dispositivo de receptor 460 pode corresponder ao dispositivo de cliente 40, onde a unidade de recuperação de 52 pode incluir a seleção e filtragem unidade 462 e receptor ROUTE 464, enquanto a unidade encapsulação inversa 54 pode corresponder a ISO BMFF pré-processador 470, ISO BMFF processador meios 468, e outros processadores de objetos 466.[00160] Figure 12 is a conceptual diagram illustrating an example set of components of a receiving device 460, including a selection and filtering unit 462, a ROUTE receiver 464, other object processors 466, ISO BMFF processor media 468 , and ISO BMFF preprocessor 470. The receiver device 460 may correspond to the client device 40, where the recovery unit 52 may include the selection and filtering unit 462 and receiver ROUTE 464, while the reverse encapsulation unit 54 may correspond the ISO BMFF preprocessor 470, ISO BMFF media processor 468, and other object processors 466.

[00161] Neste exemplo, receptor ROUTE 464 fornece o LSID com descrições de conteúdo para seleção e de filtragem da unidade 462. A partir da unidade de informação, de seleção e de filtragem 462 podem selecionar os componentes apropriados, que devem ser enviados para os processadores (por exemplo, a ISO BMFF pré-processador 470, processador de mídia ISO BMFF 468, e outro processador de objeto 466).[00161] In this example, ROUTE receiver 464 provides the LSID with content descriptions for selection and filtering unit 462. From the information, selection and filtering unit 462 can select the appropriate components, which should be sent to the processors (e.g., the ISO BMFF preprocessor 470, ISO BMFF media processor 468, and other object processor 466).

[00162] Ao aplicar o princípio acima, a capacidade de extensão pode ser garantida com novos esquemas e extensões. O sistema mantém compatível com implementações baseadas em DASH. Além disso, o processador de mídia ISO BMFF 468 também pode selecionar ou rejeitar determinados fluxos de mídia sobre o seu nível.[00162] By applying the above principle, extensibility can be guaranteed with new schemes and extensions. The system remains compatible with DASH-based implementations. Furthermore, the ISO BMFF 468 media processor can also select or reject certain media streams on its level.

[00163] Os cabeçalhos LCT podem ser flexivelmente usados para sinalizar certas propriedades. No entanto, o uso dos cabeçalhos deve ser obrigatório para ROUTE. Isto é discutido abaixo.[00163] LCT headers can be flexibly used to signal certain properties. However, the use of headers must be mandatory for ROUTE. This is discussed below.

[00164] Em uma LSID que transporta os fluxos de mídia (indicado pelo Tipo de Conteúdo xxx/MP4), a Tabela 1 fornece uma configuração de campo ponto de código. Isso permite que o emissor e o receptor para operar sem a FDT e o MPD. TABELA 1: Atribuição de Ponto de Código para Fluxos de Mídia com tipo de conteúdo xxx/mp4 [00164] In an LSID that carries media streams (indicated by Content Type xxx/MP4), Table 1 provides a code point field configuration. This allows the sender and receiver to operate without the FDT and the MPD. TABLE 1: Code Point Assignment for Media Streams with xxx/mp4 content type

[00165] Os seguintes cabeçalhos LCT podem ser utilizados em MPD - menos ROUTE: . TSI sinaliza uma única representação à base de ISO BMFF . O TOI é utilizado para assinalar os objetos. Os segmentos de mídia dentro de um período de conteúdo devem ser enviados com o aumento do número TOI, isto é, os objetos são aumentados em 1. Apenas em períodos de conteúdo Isto pode mudar. Segmento de mídia TOIs só pode usar o espaço para que o primeiro bit do TOI esteja definido para 1. Segmentos não-mídia podem usar o espaço TOI para o qual o primeiro bit é definido como 0. . Ponto de código é utilizado como documentado na seção 3.6.2. . Os bits de PSI são usados como se segue: . Se o primeiro bit é definido como 0, então a sinalização de liberação baseada no tempo é aplicada: ■ Se o segundo bit é definido como 0, então o campo de controle de congestionamento não é utilizada. ■ Se o segundo bit é ajustado para 1, então o campo de controle de congestionamento contém um carimbo de tempo na frequência de relógio de 90 kHz. ■ Se o primeiro bit é definido como 1, em seguida, ■ O segundo bit sinaliza o sinalizador de libertação para o objeto. . Campo de controle de congestionamento pode ser usado para sinalizar o carimbo de hora em frequência de relógio de 90 kHz.[00165] The following LCT headers can be used in MPD - less ROUTE: . TSI signals a single representation based on ISO BMFF. TOI is used to mark objects. Media segments within a content period must be sent with increasing TOI number, i.e. objects are increased by 1. Only in content periods This may change. Media segment TOIs can only use the space for which the first bit of the TOI is set to 1. Non-media segments can use the TOI space for which the first bit is set to 0. Code point is used as documented in section 3.6.2. . The PSI bits are used as follows: . If the first bit is set to 0, then time-based release signaling is applied: ■ If the second bit is set to 0, then the congestion control field is not used. ■ If the second bit is set to 1, then the congestion control field contains a timestamp at the clock frequency of 90 kHz. ■ If the first bit is set to 1, then ■ The second bit signals the release flag for the object. . Congestion control field can be used to signal the time stamp at 90 kHz clock frequency.

[00166] Os seguintes cabeçalhos de extensão exemplo LCT são definidos: ■ tempo de liberação inicial em TTT: Especifica o tempo de lançamento mais recente dos dados contidos neste pacote no tempo TTT. Um cabeçalho de extensão de 32 bits de tamanho seria adequado. ■ tempo de liberação inicial em NTP: Especifica o tempo de lançamento exata dos atuais bytes iniciais do objeto em tempo NTP. Mais uma vez, de 32 bits pode ser apropriado, fornecendo pelo meio 32 bits de um timestamp NTP.[00166] The following example LCT extension headers are defined: ■ initial release time in TTT: Specifies the latest release time of the data contained in this packet in TTT time. An extension header of 32 bits in size would be adequate. ■ initial release time in NTP: Specifies the exact release time of the object's current initial bytes in NTP time. Again, 32-bit may be appropriate, providing in between 32 bits of an NTP timestamp.

[00167] Supõe-se que os procedimentos de envio de Opção 1 são escolhidos abaixo. As variantes para as opções 2 e 3 são opções para estudo posterior, e pode ser usado em conjunto com as técnicas descritas abaixo ou outras técnicas. O seguinte comportamento envio é considerado sem usar o MPD para uma determinada apresentação de mídia: ■ Fragmentos LSID podem ser fornecidos por carregamento. O Os fragmentos LSID podem ser atualizados para sinalizar qualquer alteração na oferta de serviços. o Fragmentos LSID descrevem todos os componentes de transmissão do serviço. o Um descritor de conteúdo pode ser adicionado ao descrever as propriedades de cada componente do meio. O descritor de conteúdo deve fornecer informação suficiente para que o receptor ROUTE pode escolher ou rejeitar determinados componentes. ■ Geralmente, apenas uma única representação de cada componente (Adaptação Set) é distribuída. No entanto, se diferentes representações são distribuídas para o mesmo conjunto de Adaptação, em seguida, o LSID pode conter informação suficiente para diferenciar os componentes, por exemplo, o ranking de qualidade, a resolução espacial, o parâmetro codecs necessários, etc. ■ Uma sessão LCT (identificado por um TSI) pode ser usada para cada Representação. As sessões LCT são multiplexados em nível de pacote. A TTT deve ser usada de forma consistente em sessões LCT multiplexados. ■ Cada pacote pode conter um tempo de transmissão alvo em uma base de 90 kHz. Desta vez, expressa o tempo de entrega de destino. De preferência, o tempo de decodificação dos meios de comunicação contido no BMFF ISO é usado. ■ O procedimento de envio a seguir pode ser aplicado para as representações em uma única sessão LCT: o Qualquer objeto pode ser enviada na sessão LCT. Se o objeto não é um segmento de mídia, então o bit mais significativo na TOI de pode ser 0. Se o objeto é um segmento de mídia, então o bit mais significativo na TOI pode ser 1. Um objeto tanto pode ser identificado pela atribuição estática na Tabela 1, ou um ponto de código pode ser definido no LSID. Suponha que um segmento de mídia tem um tempo de lançamento específico. IS correspondente ao segmento de mídia pode sinalizar o mesmo tempo de libertação. Note-se que o tempo de liberação só pode ser enviado no é se o segmento de mídia segue imediatamente. Segmentos de inicialização são enviados como objetos utilizando o protocolo ROUTE. Para apenas um número TOI começando com um 0 no bit mais significativo pode ser utilizado. ■ O tipo de segmento de inicialização é anunciado no Ponto de Código de acordo com a Tabela 1. ■ Se o IS encaixa num único pacote ROUTE, em seguida, ponto de código de 2, 4, ou 6 podem ser utilizados. Se o SI não se encaixa em um único pacote ROUTE, em seguida, o ponto 3 de código, 5 ou 7, podem ser utilizados. ■ Se o IS é enviado em primeiro lugar ou a linha de tempo não é contínuo, então ou ponto 2 de código ou 3 pode ser sinalizado. O IS deve usar um novo TOI. O primeiro pacote de SI pode fornecer um número aleatório para a TTT. No entanto, neste último caso e numa corrente contínua, a TTT deve ser continuada para expressar a programação de reprodução. ■ Se o SI é repetido para apoiar o acesso aleatório, em seguida, quer do ponto de código 6 ou 7, pode ser sinalizado. O TOI pode permanecer o mesmo. A TTT pode ser contínua e não diminuindo. ■ Se o IS é atualizado, mas a linha do tempo é contínuo, então o ponto 4 ou 5 código é utilizado. O IS deve usar um novo TOI. A TTT pode ser contínua e não diminuindo. ■ Juntamente com um SI, uma extensão de cabeçalho pode ser enviada que indica o tempo versão mais antiga do IS para a próxima camada na mesma escala que a TTT. Se não estiver presente, então o tempo de liberação é imediato. Segmentos de mídia (MSS) são enviados como objetos usando o protocolo ROUTE. Para MS único número TOI começando com um 1 no bit mais significativo pode ser utilizado. ■ O tipo da MS é anunciado no ponto de código de acordo com a Tabela 1. ■ Se a MS se encaixa em um único pacote ROUTE, em seguida, pode ser utilizado o ponto 8 código. Se a MS não se encaixa em um único pacote ROUTE, em seguida, pode ser utilizado o ponto 9 código. o Algumas regras adicionais podem ser necessárias.[00167] It is assumed that the Option 1 submission procedures are chosen below. The variants for options 2 and 3 are options for further study, and can be used in conjunction with the techniques described below or other techniques. The following upload behavior is considered without using MPD for a given media presentation: ■ LSID fragments can be provided by upload. The LSID fragments can be updated to signal any changes in the service offering. o LSID Fragments describe all transmission components of the service. o A content descriptor can be added to describe the properties of each medium component. The content descriptor MUST provide enough information so that the ROUTE receiver can choose or reject certain components. ■ Generally, only a single representation of each component (Adaptation Set) is distributed. However, if different representations are distributed for the same Adaptation set, then the LSID may contain enough information to differentiate the components, e.g. the quality ranking, the spatial resolution, the required codecs parameter, etc. ■ An LCT session (identified by a TSI) can be used for each Representation. LCT sessions are multiplexed at the packet level. TTT must be used consistently in multiplexed LCT sessions. ■ Each packet can contain a target transmission time on a 90 kHz basis. This time expresses the destination delivery time. Preferably, the media decoding time contained in the BMFF ISO is used. ■ The following sending procedure can be applied to representations in a single LCT session: o Any object can be sent in the LCT session. If the object is not a media segment, then the most significant bit in the TOI can be 0. If the object is a media segment, then the most significant bit in the TOI can be 1. An object can either be identified by the assignment static in Table 1, or a code point can be defined in the LSID. Suppose a media segment has a specific release time. IS corresponding to the media segment can signal the same release time. Note that the release time can only be sent at is if the media segment follows immediately. Initialization segments are sent as objects using the ROUTE protocol. For only one TOI number starting with a 0 in the most significant bit can be used. ■ The type of initialization segment is announced in the Code Point according to Table 1. ■ If the IS fits into a single ROUTE packet, then code point 2, 4, or 6 can be used. If the SI does not fit into a SINGLE ROUTE packet, then code point 3, 5 or 7 may be used. ■ If the IS is sent first or the timeline is not continuous, then either code point 2 or 3 may be flagged. IS must use a new TOI. The first SI packet may provide a random number for the TTT. However, in the latter case and in a continuous current, the TTT must be continued to express the reproduction schedule. ■ If the SI is repeated to support random access, then either code point 6 or 7 may be signaled. TOI may remain the same. TTT can be continuous and not decreasing. ■ If the IS is updated but the timeline is continuous, then the point 4 or 5 code is used. IS must use a new TOI. TTT can be continuous and not decreasing. ■ Along with an SI, a header extension can be sent that indicates the earliest version time of the IS to the next layer at the same scale as the TTT. If it is not present, then the release time is immediate. Media segments (MSS) are sent as objects using the ROUTE protocol. For MS single TOI number starting with a 1 in the most significant bit can be used. ■ The type of the MS is announced in the code point according to Table 1. ■ If the MS fits into a single ROUTE packet, then code point 8 can be used. If the MS does not fit into a SINGLE ROUTE packet then code point 9 can be used. o Some additional rules may be necessary.

[00168] A figura 13 é um diagrama conceitual que ilustra um exemplo de procedimento de envio de uma série de pacotes de exemplo. Neste exemplo, uma primeira representação inclui Segmento de Inicialização 480 e dois segmentos de mídia 482, 484, que são para ser enviado seguido por uma segunda representação com novo segmento de inicialização 486 e um segmento de mídia de comunicação posterior 488. Cada um dos segmentos utiliza TSI = 1. Ou seja, esta sessão LCT é usada. O envio dos pacotes a fim é mostrado na figura 13: • O primeiro pacote a ser enviado (pacote de segmento de inicialização 490A) corresponde ao segmento de inicialização 480, com a TTT definida como o tempo de decodificação da primeira amostra na MS sendo A. Uma TOI é selecionado para o pacote segmento de inicialização 490A, e o CP é definido como 2 para indicar um novo cronograma. O tempo de liberação do segmento de inicialização 480 está definido para um valor que é ligeiramente maior do que um para indicar quando a apresentação será iniciada. • O segundo pacote (segmento de mídia pacote 492A) é o primeiro pacote de segmento de mídia 482, e segmento de mídia 482 é fragmentado. Portanto, CP = 9. Um novo TOI é usado para indicar um novo objeto. O mesmo TTT é usado como a utilizada para o segmento de inicialização 480. Como os dados são para ser liberado juntamente com o segmento de inicialização 480, nenhuma nova RT é enviado. • Para o segundo pacote (pacote de segmento de mídia 492B) do segmento de mídia 482, um novo tempo de transmissão é definido (assumindo que contém um tempo de decodificação mais tarde) com C> A. Se B <C, então isso poderia resultar na libertação de segmento de inicialização 480 e meios de comunicação de pacotes segmento 492A para a camada seguinte. • A fim de permitir acesso aleatório, segmento de inicialização 480 será enviado de modo redundante (CP = 4) com um correspondente TTT que de pacote segmento de mídia 494A de segmento de mídia 484. Um tempo de libertação é definido na escala da TTT. • Em seguida, o segmento de mídia de comunicação 484 é enviado em dois pacotes (pacotes segmento de mídia 494A, 494B) do mesmo modo como segmento de mídia 482. Os tempos são utilizados para libertando os pacotes. Um novo TOI é utilizado, que é mais um do que o segmento de TOI meios 482. • Com um novo período de partida, um novo segmento de inicialização 486 será enviado (sob a forma de pacote de segmento de inicialização 496), que é, por conseguinte, marcado com CP = 2. Um novo TOI é usado para segmento de inicialização 486. A TTT e a RT da nova Representação deve ser uma continuação da TTT anterior, a fim de instruir sequência de reprodução e de temporização. • Subsequentemente, segmento de mídia 488 pode ser enviado como um ou mais pacotes, incluindo pacotes segmento de mídia 498.[00168] Figure 13 is a conceptual diagram illustrating an example procedure for sending a series of example packets. In this example, a first representation includes Initialization Segment 480 and two media segments 482, 484, which are to be sent followed by a second representation with new initialization segment 486 and a subsequent communication media segment 488. Each of the segments uses TSI = 1. That is, this LCT session is used. The sending of end packets is shown in figure 13: • The first packet to be sent (initialization segment packet 490A) corresponds to initialization segment 480, with the TTT defined as the decoding time of the first sample in the MS being A . A TOI is selected for the 490A initialization segment package, and the CP is set to 2 to indicate a new schedule. The release time of the initialization segment 480 is set to a value that is slightly greater than one to indicate when the presentation will begin. • The second packet (media segment packet 492A) is the first packet of media segment 482, and media segment 482 is fragmented. Therefore, CP = 9. A new TOI is used to indicate a new object. The same TTT is used as that used for the 480 initialization segment. As the data is to be flushed along with the 480 initialization segment, no new RT is sent. • For the second packet (media segment packet 492B) of media segment 482, a new transmission time is set (assuming it contains a later decoding time) with C> A. If B < C, then this could result in the release of initialization segment 480 and packet media segment 492A to the next layer. • In order to allow random access, initialization segment 480 will be sent redundantly (CP = 4) with a corresponding TTT that of media segment 494A packet of media segment 484. A release time is defined in the scale of the TTT. • Then, the communication media segment 484 is sent in two packets (media segment packets 494A, 494B) in the same way as media segment 482. The times are used for releasing the packets. A new TOI is used, which is one more than the TOI segment means 482. • With a new starting period, a new initialization segment 486 will be sent (in the form of initialization segment packet 496), which is , therefore, marked with CP = 2. A new TOI is used for initialization segment 486. The TTT and the RT of the new Representation must be a continuation of the previous TTT in order to instruct playback sequence and timing. • Subsequently, media segment 488 may be sent as one or more packets, including media segment packets 498.

[00169] Num exemplo alternativo, um MPD leve pode ser usado. Neste exemplo, o momento e a memória intermédia de sinalização e operações são o mesmo que acima, enquanto outras alterações acima para a sinalização de informações MPD não-sincronismo através de outros meios que não sejam tomadas. Em vez disso, o MPD é alterado para que esta possa conter apenas informações absolutamente necessárias para os diferentes cenários (incluindo para sintonizar e mudança de canal na transmissão), enquanto outra informação está ausente. Ao extremo, quando nenhum MPD informação é necessário, ele pode estar vazio. Quando apenas um subconjunto da informação é necessário e presente, o MPD é de peso leve e, por conseguinte, uma sobrecarga desnecessária é evitada. O remetente pode optar por colocar regulares cópias MPD escassa em algumas RAPs, e entre duas cópias regulares MPD, coloque um MPD leve em cada RAP.[00169] In an alternative example, a lightweight MPD can be used. In this example, the timing and buffering of signaling and operations are the same as above, while other changes above for signaling non-timing MPD information through other means are not taken. Instead, the MPD is changed so that it can only contain information absolutely necessary for different scenarios (including for tuning and changing channels in transmission), while other information is missing. In the extreme, when no MPD information is needed, it may be empty. When only a subset of the information is needed and present, the MPD is lightweight and therefore unnecessary overhead is avoided. The sender may choose to place regular MPD scant copies in some RAPs, and between two regular MPD copies, place one MPD light in each RAP.

[00170] Isto pode resultar em qualquer ou todas as seguintes características: • MPDs de inicialização que são simples, mas redundante uma vez que o MPD completo é recebido • O MPDs só contém as informações do componente • A temporização seria ignorada, uma vez que é acionada pela camada inferior. • Sem URLs para os segmentos são especificados como aqueles são fornecidos através do protocolo objeto • Basicamente, o identificador de conteúdo mencionado acima seria mapeado em um objeto separado.[00170] This could result in any or all of the following characteristics: • Initialization MPDs that are simple but redundant once the full MPD is received • The MPDs only contain the component information • Timing would be ignored since is driven by the lower layer. • No URLs for the segments are specified as those are provided via the object protocol • Basically, the content identifier mentioned above would be mapped into a separate object.

[00171] Neste ponto no tempo, podem ser utilizados segmentos em conformidade com o Perfil ISO BMFF ao vivo. Otimizações para um formato multimídia melhorado para tais aplicações são discutidas em Stockhammer et al., “Low Latency Video Streaming”, Pedido Provisório dos Estados Unidos 62/114.423, depositado em 10 de fevereiro de 2015, todo o conteúdo do qual está aqui incorporado por referência.[00171] At this point in time, segments conforming to the live BMFF ISO Profile may be used. Optimizations for an improved multimedia format for such applications are discussed in Stockhammer et al., “Low Latency Video Streaming,” U.S. Provisional Application 62/114,423, filed February 10, 2015, the entire contents of which are incorporated herein by reference.

[00172] Para uma oferta de serviço híbrido, o MPD pode ser importante. Um MPD unificado que descreve o conteúdo de transmissão de banda larga e distribuído podem ser utilizados, segundo o qual: • O MPD ou é entregue como um objeto na sessão de rota ou o MPD é fornecido através de banda larga somente através de um link. • Um EFDT ou é entregue como um objeto na sessão de rota ou os EFDT é fornecido através de banda larga somente através de um link. • O EFDT documenta o mapeamento entre o TOI na entrega do objeto e a URL que pode ser visto no MPD. • A temporização é então controlada pela MPD, ou seja, os segmentos transmitidos não são mais empurrados para o cliente ISO BMFF, mas o cliente DASH controla o tempo. No entanto, os detalhes são a implementação específica.[00172] For a hybrid service offering, the MPD may be important. A unified MPD that describes the broadband and distributed transmission content can be used, whereby: • The MPD is either delivered as an object in the session route or the MPD is delivered over broadband only over a link. • An EFDT is either delivered as an object in the session route or the EFDT is delivered over a broadband link only. • The EFDT documents the mapping between the TOI on object delivery and the URL that can be seen in the MPD. • The timing is then controlled by the MPD, i.e. the transmitted segments are no longer pushed to the ISO BMFF client, but the DASH client controls the timing. However, the details are implementation specific.

[00173] A figura 14 é um diagrama conceitual que ilustra um modelo cliente DASH exemplo híbrido. A unidade de recuperação 52 do dispositivo de cliente 40 da figura 1 pode ser configurada de acordo com o exemplo da figura 14. Neste exemplo, o modelo cliente DASH híbrido inclui armazenamento de receptor e de saída 506 e ROUTE cliente DASH 512. De acordo com o modelo cliente híbrido DASH, um dispositivo de cliente pode receber segmentos (por exemplo, pacote do RAP 500 e pacotes 502, 504) através transmissão ROUTE utilizando armazenamento de receptor ROUTE e armazenamento de saída 506 ou através da transmissão de unidifusão de rede 514 usando cliente DASH 512. Ao receber segmentos, seja do receptor ROUTE e memória intermédia de saída 506 proporciona os segmentos para armazenamento DASH 508 ou ISO cliente BMFF 512 fornece os segmentos ao armazenamento ISO BMFF 508.[00173] Figure 14 is a conceptual diagram illustrating an example hybrid DASH client model. The recovery unit 52 of the client device 40 of Figure 1 may be configured according to the example of Figure 14. In this example, the hybrid DASH client model includes receiver and output storage 506 and ROUTE DASH client 512. In accordance with In the DASH hybrid client model, a client device may receive segments (e.g., RAP packet 500 and packets 502, 504) through ROUTE transmission using ROUTE receiver storage and output storage 506 or through network unicast transmission 514 using DASH client 512. Upon receiving segments, either from the ROUTE receiver and output buffer 506 provides the segments to DASH storage 508 or ISO BMFF client 512 provides the segments to the ISO BMFF storage 508.

[00174] Há dois tipos exemplares de implementações para tipos de recepções para difusão: • Recepção MPD - menos: receptor ROUTE e o armazenamento de saída 506 encaminham diretamente os dados para o armazenamento ISO BMFF 508 para decodificação pelo decodificador ISO BMFF 510 e reprodução. • Recepção à base de MPD: armazenamento de receptor e de saída ROUTE 506 gera um MPD que inclui todas as informações, de tal modo que o cliente DASH 512 recupera os dados do buffer de receptor e de saída ROUTE 506 (por exemplo, agir como um servidor de proxy) e armazena os dados para a ISO armazenamento BMFF 508 para decodificação e de reprodução.[00174] There are two exemplary types of implementations for types of receptions for broadcast: • MPD reception - minus: ROUTE receiver and output store 506 directly forward the data to the ISO BMFF store 508 for decoding by the ISO BMFF decoder 510 and playback. • MPD-based receive: ROUTE 506 receiver and output buffer generates an MPD that includes all information such that the DASH client 512 retrieves the data from the ROUTE 506 receiver and output buffer (e.g., act as a proxy server) and stores the data to the ISO BMFF 508 storage for decoding and playback.

[00175] Ambas as versões são possíveis, e são uma escolha de implementação. Além disso, um cliente híbrido pode ser implementado que usa transmissão de banda larga e no modo como mostrado na figura 14. Neste caso, o armazenamento e saída receptor ROUTE 506 fornece os dados recebidos para armazenamento ISO BMFF 508 após a recepção de dados a partir do fluxo de transmissão. Uma vez que a banda larga é adicionada, a relação é criada pelo MPD. Cliente DASH 512 atribui URLs para TOIs e, portanto, pode mudar para banda larga com base nas informações do MPD.[00175] Both versions are possible, and are an implementation choice. Additionally, a hybrid client can be implemented that uses broadband transmission and in the mode as shown in Figure 14. In this case, the storage and output receiver ROUTE 506 delivers the received data to ISO storage BMFF 508 after receiving data from of the transmission stream. Once broadband is added, the relationship is created by MPD. DASH client 512 assigns URLs to TOIs and therefore can switch to broadband based on MPD information.

[00176] A figura 15 é um fluxograma que ilustra um exemplo de método para o transporte de dados de mídia de uma apresentação de mídia através de sessões LCT de acordo com as técnicas desta revelação. O exemplo da figura 15 é explicado com respeito ao dispositivo de servidor 60 e um dispositivo de cliente 40 da figura 1. No entanto, deve ser compreendido que outros dispositivos podem ser configurados para realizar estas técnicas. Por exemplo, os dispositivos das figuras 4, 5, 6, 11, 12, ou 14 podem ser configurados para realizar estas técnicas.[00176] Figure 15 is a flowchart illustrating an example method for transporting media data from a media presentation through LCT sessions in accordance with the techniques of this disclosure. The example of Figure 15 is explained with respect to the server device 60 and a client device 40 of Figure 1. However, it should be understood that other devices may be configured to perform these techniques. For example, the devices of Figures 4, 5, 6, 11, 12, or 14 can be configured to perform these techniques.

[00177] Inicialmente, o dispositivo de servidor 60 pode obter dados para uma pluralidade de representações (550) de uma apresentação de mídia. Por exemplo, o dispositivo de servidor 60 pode receber o conteúdo preparado a partir do dispositivo de apresentação de conteúdo 20 (figura 1). Em alternativa, o dispositivo de servidor 60 pode incluir codificadores dos meios (tais como codificador de áudio 26 e o codificador de vídeo 28) e/ou uma unidade de encapsulação (tal como a unidade de encapsulação 30) para preparar as representações para distribuição. A pluralidade de representações podem corresponder às representações 68 de conteúdo de multimídia 64 da figura 1. Além disso, o dispositivo de servidor 60 pode obter um arquivo de manifesto, tal como um MPD, para a pluralidade de representações (por exemplo, arquivo de manifesto 66 da figura 1).[00177] Initially, server device 60 may obtain data for a plurality of representations (550) of a media presentation. For example, the server device 60 may receive content prepared from the content presentation device 20 (Figure 1). Alternatively, the server device 60 may include media encoders (such as audio encoder 26 and video encoder 28) and/or an encapsulation unit (such as encapsulation unit 30) to prepare the representations for distribution. The plurality of representations may correspond to the representations 68 of multimedia content 64 of Figure 1. Additionally, the server device 60 may obtain a manifest file, such as an MPD, for the plurality of representations (e.g., manifest file 66 in figure 1).

[00178] O dispositivo Servidor 60 pode então atribuir as representações de sessões LCT (552). Em geral, cada uma das sessões de LCT pode transportar dados de uma das representações, de tal modo que existe uma relação de um - para - um entre as sessões de LCT e representações. Além disso, o dispositivo de servidor 60 pode construir um LSID para as sessões de LCT indicando uma correspondência entre as representações e as sessões de LCT (554). O LSID pode sinalizar, por exemplo, as relações entre TSI para as sessões de LCT e identificadores de representação (por exemplo, larguras de banda para as representações). Como observado acima, o dispositivo de servidor 60 também pode construir o LSID para descrever combinações IP e a porta para as várias sessões LCT.[00178] The Server device 60 may then assign LCT session representations (552). In general, each of the LCT sessions can carry data from one of the representations, such that there is a one-to-one relationship between the LCT sessions and representations. Additionally, the server device 60 may construct an LSID for the LCT sessions indicating a correspondence between the representations and the LCT sessions (554). The LSID can signal, for example, relationships between TSI for LCT sessions and impersonation identifiers (e.g., bandwidths for the impersonations). As noted above, the server device 60 may also construct the LSID to describe IP and port combinations for the various LCT sessions.

[00179] O dispositivo de servidor 60 pode construir ainda mais a LSID para incluir dados que convencionalmente ser incluídas no arquivo de manifesto, tais como, por exemplo, atributos, incluindo qualquer ou todos @id, @group, @ lang, @contentType, @par (relação de aspecto da imagem), elementos de papel, os elementos de acessibilidade, elementos de ponto de vista, elementos de classificação, propriedades do segmento de segmentos da representação, @profiles, @largura e @height, @sar, @framerate, @audiosamplingRate, @mimeType, @codecs, @scanType, FramePacking, AudioChannelConfiguration, ContentProtection, EssentialProperty, SupplementalProperty, e/ou InbandEventStream, como discutido acima.[00179] Server device 60 may further construct the LSID to include data that would conventionally be included in the manifest file, such as, for example, attributes including any or all @id, @group, @lang, @contentType, @par (image aspect ratio), role elements, accessibility elements, viewpoint elements, classification elements, segment representation properties, @profiles, @width and @height, @sar, @ framerate, @audiosamplingRate, @mimeType, @codecs, @scanType, FramePacking, AudioChannelConfiguration, ContentProtection, EssentialProperty, SupplementalProperty, and/or InbandEventStream, as discussed above.

[00180] Além disso, o dispositivo de servidor 60 pode construir pacotes das sessões LCT que incluem um cabeçalho, em conformidade com, por exemplo, o exemplo da figura 9. Os pacotes de dados podem incluir segmentos das representações. A informação do cabeçalho pode indicar, por exemplo, TSI e/ou TOIs de representações e segmentos correspondente.[00180] Furthermore, the server device 60 may construct packets of the LCT sessions that include a header, in accordance with, for example, the example of Figure 9. The data packets may include segments of the representations. The header information may indicate, for example, TSI and/or TOIs of corresponding representations and segments.

[00181] O dispositivo de servidor 60 pode então enviar a LSID e os dados das representações através de sessões LCT correspondentes (556). O dispositivo de cliente 40 pode receber a LSID para as sessões de LCT (558). Embora não esteja representado no exemplo da figura 15, dispositivo de servidor 60 também pode enviar o arquivo de manifesto periodicamente, por exemplo, com certos pontos de acesso aleatório das representações. Em particular, neste exemplo, presume-se que o dispositivo de cliente 40 recebe o LSID antes de receber o arquivo de manifesto de (por exemplo, entre arquivos de manifesto). No entanto, de acordo com as técnicas desta revelação, o dispositivo de cliente 40 pode acessar os dados de mídia de uma ou mais das sessões de LCT (e, portanto, as representações correspondentes) usando o LSID, sem (ou antes, de) receber o arquivo de manifesto.[00181] The server device 60 may then send the LSID and representation data through corresponding LCT sessions (556). The client device 40 may receive the LSID for the LCT sessions (558). 15, server device 60 may also send the manifest file periodically, for example, with certain random access points of the representations. In particular, in this example, it is assumed that the client device 40 receives the LSID before receiving the manifest file from (e.g., between manifest files). However, according to the techniques of this disclosure, the client device 40 can access the media data of one or more of the LCT sessions (and therefore the corresponding representations) using the LSID, without (or before) receive the manifest file.

[00182] Por exemplo, o dispositivo de cliente 40 pode determinar as correspondências entre sessões LCT e representações. O dispositivo de cliente 40 também pode determinar as características das representações usando dados sinalizados no LSID. Por exemplo, o dispositivo de cliente 40 pode determinar qual das representações fósforos de codificação e render características suportadas por elementos de dispositivo de cliente 40, tal como o decodificador de áudio 46, de vídeo decodificador 48, uma saída de áudio 42, de vídeo e de saída 44. Com base nas características e suportados codificação e renderização características das representações, dispositivo de cliente 40 pode selecionar as representações usando o LSID (560). Por exemplo, dispositivo de cliente 40 pode selecionar as representações que tenham características de codificação e renderização suportados pelos elementos do dispositivo de cliente 40.[00182] For example, client device 40 may determine correspondences between LCT sessions and representations. The client device 40 may also determine the characteristics of the representations using data signaled in the LSID. For example, client device 40 may determine which of the representations matches encoding and rendering characteristics supported by elements of client device 40, such as audio decoder 46, video decoder 48, an audio output 42, video and output 44. Based on the characteristics and supported encoding and rendering characteristics of the representations, client device 40 may select the representations using the LSID (560). For example, client device 40 may select representations that have encoding and rendering characteristics supported by elements of client device 40.

[00183] O dispositivo de cliente 40 pode extrair ainda mais os pacotes das sessões de LCT as representações selecionados (562). Cada pacote pode corresponder a um segmento da representação. Cada segmento da representação pode ser transmitido sob a forma de um ou mais pacotes. Como discutido acima no que diz respeito aos vários exemplos da figura 10, os pacotes podem incluir informação indicando quando os pacotes podem ser liberados. Assim, após todos os pacotes para um segmento serem recebidos, a unidade de recuperação 52 do dispositivo de cliente 40 pode enviar um segmento reconstruído para a unidade de encapsulação inversa 50, o que pode em última análise encapsular inversamente dados multimídia e enviar os dados de mídia para decodificadores adequados, por exemplo, um decodificador de áudio 46 ou decodificador de vídeo 48. Desse modo, o dispositivo de cliente 40 pode enviar dados de mídia a partir dos pacotes de se apropriar decodificadores (564) para a decodificação, e em última análise, a apresentação.[00183] The client device 40 may further extract packets from the LCT sessions and selected representations (562). Each packet can correspond to a segment of the representation. Each segment of the representation can be transmitted in the form of one or more packets. As discussed above with respect to the various examples of Figure 10, packets may include information indicating when packets may be released. Thus, after all packets for a segment are received, the recovery unit 52 of the client device 40 may send a reconstructed segment to the reverse encapsulation unit 50, which may ultimately reverse encapsulate multimedia data and send the media to suitable decoders, for example, an audio decoder 46 or video decoder 48. In this way, the client device 40 can send media data from the packets to appropriate decoders (564) for decoding, and ultimately analysis, presentation.

[00184] Dessa maneira, o método de exemplo da figura 15 representa um exemplo de um método incluindo a determinação de uma pluralidade de representações de uma apresentação de mídia de fluxo contínuo adaptável dinâmico sobre HTTP (DASH) a partir de uma descrição de instância de sessão de transporte de codificação em camadas (LCT), LSID, em que o LSID inclui informação representativa de uma pluralidade de sessões de LCT, cada uma das sessões LCT incluindo dados de uma respectiva uma das representações, e iniciar o consumo de uma ou mais das representações da apresentação de mídia DASH usando o LSID e sem o uso de um arquivo de manifesto para a apresentação de mídia DASH, em que o iniciar o consumo compreende receber pacotes das sessões de LCT, incluindo porções de dados de um ou mais das representações, e fornecendo os dados dos pacotes para um decodificador de multimídia.[00184] Thus, the example method of Figure 15 represents an example of a method including determining a plurality of representations of a dynamic adaptive streaming media presentation over HTTP (DASH) from an instance description of layered coding transport (LCT) session, LSID, wherein the LSID includes information representative of a plurality of LCT sessions, each of the LCT sessions including data from a respective one of the representations, and initiating consumption of one or more of representations of the DASH media presentation using the LSID and without the use of a manifest file for the DASH media presentation, wherein initiating consumption comprises receiving packets from the LCT sessions, including portions of data from one or more of the representations , and providing the packet data to a multimedia decoder.

[00185] O método de exemplo da figura 15 representa também um exemplo de um método que inclui a construção de uma descrição de instância de sessão de transporte de codificação em camadas (LCT), LSID, incluindo informação representativa de uma pluralidade de sessões de LCT, cada uma das sessões de LCT incluindo dados de uma respectiva uma de uma pluralidade de representações de uma apresentação de mídia de Transmissão Adaptável Dinâmica sobre HTTP (DASH), caracterizado pelo LSID indica correspondências entre as sessões de LCT e as representações, produzindo o LSID, e saída de dados das representações nas sessões LCT correspondentes.[00185] The example method of Figure 15 also represents an example of a method that includes constructing a layered coding transport (LCT) session instance description, LSID, including information representative of a plurality of LCT sessions. , each of the LCT sessions including data from a respective one of a plurality of representations of a Dynamic Adaptive Streaming over HTTP (DASH) media presentation, characterized by the LSID indicates correspondences between the LCT sessions and the representations, producing the LSID , and outputting data from the representations in the corresponding LCT sessions.

[00186] A figura 16 é um fluxograma que ilustra outro exemplo de método para o transporte de dados de mídia de uma apresentação de mídia através de sessões LCT de acordo com as técnicas desta revelação. Neste exemplo, o dispositivo de cliente 40 determina inicialmente uma pluralidade de representações de uma apresentação de mídia de fluxo contínuo adaptável dinâmico sobre HTTP (DASH) de uma descrição de instância de sessão de transporte de codificação em camadas (LCT), LSID, em que o LSID inclui informações representantes de uma pluralidade de sessões de LCT, cada uma das sessões LCT incluindo dados de um respectivo um das representações (580). O dispositivo de cliente 40, em seguida, inicia o consumo de uma ou mais das representações da apresentação de mídia DASH usando o LSID e sem o uso de um arquivo de manifesto para a apresentação de mídia DASH (582). Em particular, quando se inicia o consumo, o dispositivo de cliente 40 recebe pacotes das sessões de LCT, incluindo porções de dados de um ou mais das representações (584), e fornece os dados dos pacotes para um decodificador meios de comunicação (586).[00186] Figure 16 is a flowchart illustrating another example method for transporting media data from a media presentation through LCT sessions in accordance with the techniques of this disclosure. In this example, the client device 40 initially determines a plurality of representations of a dynamic adaptive streaming media presentation over HTTP (DASH) from a layered coding transport (LCT) session instance description, LSID, wherein the LSID includes information representing a plurality of LCT sessions, each of the LCT sessions including data from a respective one of the representations (580). The client device 40 then initiates consumption of one or more of the DASH media presentation representations using the LSID and without the use of a manifest file for the DASH media presentation (582). In particular, when consumption begins, the client device 40 receives packets from the LCT sessions, including portions of data from one or more of the representations (584), and provides the packet data to a decoder (586). .

[00187] A figura 17 é um fluxograma que ilustra outro exemplo de método para o transporte de dados de mídia de uma apresentação de mídia através de sessões LCT de acordo com as técnicas desta revelação. Neste exemplo, o dispositivo de servidor 60 constrói descrição de instância de sessão de transporte de codificação em camadas (LCT), LSID, incluindo informações representativas de uma pluralidade de sessões de LCT, cada uma das sessões de LCT, incluindo dados de uma respectiva uma de uma pluralidade de representações de uma mídia de comunicação de apresentação adaptável dinâmica ao vivo através de HTTP (DASH), em que o LSID indica correspondências entre as sessões de LCT e as representações (590). O dispositivo de servidor 60, em seguida, emite o LSID (592) e dados saídas das representações nas sessões LCT correspondentes (594).[00187] Figure 17 is a flowchart illustrating another example method for transporting media data from a media presentation through LCT sessions in accordance with the techniques of this disclosure. In this example, server device 60 constructs layered coding transport (LCT) session instance description, LSID, including information representative of a plurality of LCT sessions, each of the LCT sessions including data from a respective one of a plurality of representations of a live dynamic adaptive presentation communication media over HTTP (DASH), wherein the LSID indicates correspondences between the LCT sessions and the representations (590). The server device 60 then issues the LSID (592) and outputs data from the representations in the corresponding LCT sessions (594).

[00188] Em um ou mais exemplos, as funções descritas podem ser implementadas em hardware, software, firmware, ou qualquer combinação dos mesmos. Se implementadas em software, as funções podem ser armazenadas ou transmitidas como uma ou mais instruções ou código num meio legível por computador e executado por uma unidade de processamento baseado em hardware. Meios legíveis por computador podem incluir meios de armazenamento de leitura por computador, o que corresponde a um suporte material, tais como meios de armazenamento de dados ou meios de comunicação, incluindo qualquer meio que facilite a transferência de um programa de computador a partir de um lugar para outro, por exemplo, de acordo com um protocolo de comunicação. Deste modo, meios legíveis por computador podem corresponder geralmente a (1) meios de armazenamento legível por computador tangível que é não transitório ou (2) um meio de comunicação, tal como uma onda portadora ou sinal. Meios de armazenamento de dados pode ser qualquer material disponível que pode ser acedida por um ou mais computadores ou um ou mais processadores para recuperar instruções, código e/ou estruturas de dados para a implementação das técnicas descritas na presente memória descritiva. Um produto de programa de computador pode incluir um meio legível por computador.[00188] In one or more examples, the described functions can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, functions may be stored or transmitted as one or more instructions or code in a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to a material carrier, such as data storage media or communication media, including any medium that facilitates the transfer of a computer program from a place to another, for example, according to a communication protocol. Thus, computer-readable media may generally correspond to (1) tangible computer-readable storage media that is non-transitory or (2) a communication medium, such as a carrier wave or signal. Data storage media may be any available material that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementing the techniques described herein. A computer program product may include a computer-readable medium.

[00189] A título de exemplo, e não como limitação, tais meios de armazenamento legíveis por computador podem compreender RAM, ROM, EEPROM, CD-ROM ou outro armazenamento em disco óptico, armazenamento em disco magnético ou outros dispositivos de armazenamento magnético, memória flash, ou qualquer outro meio que possa ser utilizado para armazenar o código de programa desejado sob a forma de instruções ou estruturas de dados, e que pode ser acedido por um computador. Além disso, qualquer conexão é denominada corretamente como um meio legível por computador. Por exemplo, se as instruções são transmitidas de um site, servidor ou outra fonte remota utilizando um cabo coaxial, cabo de fibra óptica, par trançado, linha de assinante digital (DSL) ou tecnologias sem fios tais como infravermelhos, rádio e microondas, então o cabo coaxial, cabo de fibra óptica, o par torcido, DSL, ou tecnologias sem fios, tais como infravermelho, rádio e microondas estão incluídos na definição de forma. Deve ser entendido, no entanto, que os meios de armazenamento de leitura por computador e meios de armazenamento de dados não incluem conexões, as ondas de transporte, sinais, ou outros meios transitórios, mas são em vez disso dirigido de forma não transitória, meios de armazenamento tangível. Disco e disco, como aqui utilizado, incluem disco compacto (CD), disco laser, disco óptico, disco versátil digital (DVD), disquete e disco Blu-ray onde os discos geralmente reproduzem dados magneticamente, enquanto que os discos reproduzem dados opticamente com lasers. Combinações dos anteriores também devem ser incluídas no âmbito da mídia legível por computador.[00189] By way of example, and not as a limitation, such computer-readable storage media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, memory flash, or any other medium that can be used to store the desired program code in the form of instructions or data structures, and that can be accessed by a computer. Furthermore, any connection is correctly termed as a computer-readable medium. For example, if instructions are transmitted from a site, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then Coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the form definition. It should be understood, however, that computer-readable storage media and data storage media do not include connections, transport waves, signals, or other transient media, but are instead directed non-transitory media. of tangible storage. Disc and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc where discs generally reproduce data magnetically, while disks reproduce data optically with lasers. Combinations of the above must also be included within the scope of computer-readable media.

[00190] As instruções podem ser executadas por um ou mais processadores, tais como um ou mais processadores de sinal digital (DSP), microprocessadores de uso geral, a aplicação específica de circuitos integrados (ASIC), arranjos de portas lógicas programáveis no campo (FPGA) ou outro equivalente integrado ou circuitos lógicos discretos. Por conseguinte, o termo “processador” tal como aqui utilizado pode referir-se a qualquer da estrutura anterior ou qualquer outra estrutura adequada para aplicação das técnicas aqui descritas. Além disso, em alguns aspectos, a funcionalidade aqui descrita pode ser fornecida dentro de módulos de hardware e/ou software dedicado configurados para a codificação e decodificação, ou incorporada em um codec combinado. Além disso, as técnicas podem ser totalmente implementadas em um ou mais circuitos ou elementos lógicos.[00190] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSP), general purpose microprocessors, application specific integrated circuits (ASIC), field programmable logic gate arrays ( FPGA) or other equivalent integrated or discrete logic circuits. Therefore, the term "processor" as used herein may refer to any of the foregoing structure or any other structure suitable for applying the techniques described herein. Furthermore, in some aspects, the functionality described herein may be provided within dedicated hardware and/or software modules configured for encoding and decoding, or incorporated into a combined codec. Furthermore, the techniques can be fully implemented in one or more circuits or logic elements.

[00191] As técnicas da presente revelação podem ser implementadas numa vasta variedade de dispositivos ou aparelhos, incluindo um monofone sem fios, um circuito integrado (IC) ou um conjunto de CIs (por exemplo, um conjunto de chips). Vários componentes, módulos ou unidades estão descritos na presente memória descritiva para realçar os aspectos funcionais de dispositivos configurados para executar as técnicas divulgadas, mas não precisam necessariamente de realização por diferentes unidades de hardware. Em vez disso, tal como descrito acima, várias unidades podem ser combinadas em uma unidade de hardware codec ou fornecida por um conjunto de unidades de hardware interligados, incluindo um ou mais processadores, conforme descrito acima, em conjunto com o software e/ou firmware adequado.[00191] The techniques of the present disclosure can be implemented in a wide variety of devices or apparatus, including a wireless handset, an integrated circuit (IC), or a set of ICs (e.g., a chip set). Various components, modules or units are described in this specification to highlight the functional aspects of devices configured to perform the disclosed techniques, but do not necessarily need to be performed by different hardware units. Instead, as described above, multiple units may be combined into a codec hardware unit or provided by a set of interconnected hardware units, including one or more processors, as described above, together with software and/or firmware. adequate.

[00192] Vários exemplos foram descritos. Esses e outros exemplos estão dentro do âmbito das reivindicações seguintes.[00192] Several examples have been described. These and other examples are within the scope of the following claims.

Claims (12)

1. Método para receber dados de mídia, o método caracterizado pelo fato de que compreende: determinar uma pluralidade de representações de uma apresentação de mídia de Fluxo Contínuo Adaptável Dinâmico sobre HTTP, DASH, a partir de uma descrição de instância de sessão de transporte de codificação em camadas (LCT), LSID, recebida, em que a LSID inclui informação representativa de uma pluralidade de sessões LCT, cada uma dentre as sessões LCT incluindo dados de uma representação respectiva dentre as representações e em que a LSID indica correspondências entre as sessões LCT e as representações; e iniciar consumo (560) de uma ou mais dentre as representações da apresentação de mídia DASH utilizando a LSID, em que a iniciação de consumo compreende: determinar as correspondências entre as sessões LCT e as representações com base na LSID; receber (562) um primeiro conjunto de dados, incluindo pacotes das sessões LCT incluindo porções de dados das uma ou mais dentre as representações, até um primeiro tempo de reprodução, antes de receber um arquivo de manifesto; fornecer dados (564) dos pacotes a um decodificador de mídia. receber um arquivo de manifesto, após receber o primeiro conjunto de dados; e receber um segundo conjunto de dados, diferente do primeiro conjunto de dados, da apresentação de mídia DASH utilizando o arquivo de manifesto, o segundo conjunto de dados tendo tempos de reprodução seguindo o primeiro tempo de reprodução.1. Method for receiving media data, the method comprising: determining a plurality of representations of a Dynamic Adaptive Streaming over HTTP, DASH, media presentation from a transport session instance description of layered coding (LCT), LSID, received, wherein the LSID includes information representative of a plurality of LCT sessions, each of the LCT sessions including data from a respective representation among the representations, and wherein the LSID indicates correspondences between the sessions LCT and representations; and initiating consumption (560) of one or more of the representations of the DASH media presentation using the LSID, wherein initiating consumption comprises: determining the correspondences between the LCT sessions and the representations based on the LSID; receiving (562) a first set of data, including packets from the LCT sessions including portions of data from the one or more of the representations, up to a first playback time, before receiving a manifest file; providing packet data (564) to a media decoder. receive a manifest file, after receiving the first set of data; and receiving a second set of data, different from the first set of data, from the DASH media presentation using the manifest file, the second set of data having playback times following the first playback time. 2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: determinar pelo menos uma dentre características de codificação ou características de renderização das representações da apresentação de mídia DASH a partir de um ou mais descritores de conteúdo da LSID; e selecionar as uma ou mais dentre as representações com base nas características de codificação ou características de renderização determinadas.2. The method of claim 1, further comprising: determining at least one of encoding characteristics or rendering characteristics of DASH media presentation representations from one or more LSID content descriptors; and selecting the one or more of the representations based on the determined coding characteristics or rendering characteristics. 3. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que as uma ou mais características de codificação ou características de renderização incluem um ou mais dentre codec, informação de acessibilidade, qualidade, resolução espacial, ponto de vista, classificação, atributo de perfil de um conjunto de adaptação, relação de aspecto de amostra, taxa de quadros, taxa de amostragem de áudio, tipo MIME, tipo de varredura, informação de empacotamento de quadro, configuração de canal de áudio, preparação de conteúdo, propriedade essencial, propriedade suplementar, ou fluxo de evento em banda.3. Method according to claim 2, characterized by the fact that the one or more encoding characteristics or rendering characteristics include one or more of codec, accessibility information, quality, spatial resolution, point of view, classification, attribute profile of an adaptation set, sample aspect ratio, frame rate, audio sample rate, MIME type, scan type, frame packaging information, audio channel configuration, content preparation, essential property, supplementary property, or in-band event stream. 4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente usar o arquivo de manifesto para combinar entrega por difusão e unidifusão de dados da apresentação de mídia DASH.4. The method of claim 1, further comprising using the manifest file to combine broadcast and unicast delivery of DASH media presentation data. 5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o arquivo de manifesto é uma descrição de apresentação de mídia, MPD.5. The method of claim 1, wherein the manifest file is a media presentation description, MPD. 6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que pelo menos uma dentre as uma ou mais representações inclui um segmento de inicialização e um ou mais segmentos de mídia formatados de acordo com um formato de segmento DASH, e em que pacotes compreendendo dados para o segmento de inicialização ou para os segmentos de mídia compreendem adicionalmente cabeçalhos LCT.6. The method of claim 1, wherein at least one of the one or more representations includes an initialization segment and one or more media segments formatted in accordance with a DASH segment format, and wherein packets comprising data for the boot segment or for the media segments additionally comprise LCT headers. 7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente usar campos de identificador de sessão de transporte, TSI, de cabeçalhos LCT dos pacotes da descrição de sessões LCT para determinar correspondências entre as sessões LCT e as representações.7. The method of claim 1, further comprising using transport session identifier, TSI, fields from LCT headers of LCT session description packets to determine correspondences between LCT sessions and representations. 8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente determinar tempos de liberação para dados de pacotes das sessões LCT a partir de pelo menos um dentre bits de indicação específicos de protocolo, PSI, de cabeçalhos LCT dos pacotes ou cabeçalhos de extensão dos cabeçalhos LCT dos pacotes.8. The method of claim 1, further comprising determining release times for LCT session packet data from at least one of protocol-specific indication bits, PSI, of LCT packet headers. or extension headers of packets' LCT headers. 9. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente determinar tempos de transmissão alvo para pacotes das sessões LCT a partir de informação de controle de congestionamento de cabeçalhos LCT dos pacotes.9. The method of claim 1, further comprising determining target transmission times for LCT session packets from congestion control information from LCT headers of the packets. 10. Dispositivo (40) para receber dados de mídia, o dispositivo caracterizado pelo fato de que compreende: meios (54) para determinar uma pluralidade de representações de uma apresentação de mídia de Fluxo Contínuo Adaptável Dinâmico sobre HTTP, DASH, a partir de uma descrição de instância de sessão de transporte de codificação em camadas (LCT), LSID, recebida, em que a LSID inclui informação representativa de uma pluralidade de sessões LCT, cada uma dentre as sessões LCT incluindo dados de uma representação respectiva dentre as representações e em que a LSID indica correspondências entre as sessões LCT e as representações; e meios (52) para iniciar consumo de uma ou mais dentre as representações da apresentação de mídia DASH utilizando a LSID, em que os meios para iniciar consumo compreendem: meios para determinar as correspondências entre as sessões LCT e as representações com base na LSID; meios (52) para receber um primeiro conjunto de dados, incluindo pacotes das sessões LCT incluindo porções de dados das uma ou mais dentre as representações, até um primeiro tempo de reprodução, antes de receber um arquivo de manifesto; meios (50) para fornecer dados dos pacotes a um decodificador de mídia, em que os meios (52) para recebe são dispostos para receber um arquivo de manifesto, após receber o primeiro conjunto de dados; e meios para receber um segundo conjunto de dados, diferente do primeiro conjunto de dados, da apresentação de mídia DASH utilizando o arquivo de manifesto, o segundo conjunto de dados tendo tempos de reprodução seguindo o primeiro tempo de reprodução.10. Device (40) for receiving media data, the device characterized by the fact that it comprises: means (54) for determining a plurality of representations of a Dynamic Adaptive Streaming over HTTP, DASH, media presentation from a layered coding transport (LCT) session instance description, LSID, received, wherein the LSID includes information representative of a plurality of LCT sessions, each of the LCT sessions including data from a respective representation of the representations and in that the LSID indicates correspondences between LCT sessions and representations; and means (52) for initiating consumption of one or more of the DASH media presentation representations using the LSID, wherein the means for initiating consumption comprises: means for determining correspondences between the LCT sessions and the representations based on the LSID; means (52) for receiving a first set of data, including packets from the LCT sessions including portions of data from the one or more of the representations, up to a first playback time, before receiving a manifest file; means (50) for providing packet data to a media decoder, wherein the receiving means (52) are arranged to receive a manifest file after receiving the first set of data; and means for receiving a second set of data, different from the first set of data, from the DASH media presentation using the manifest file, the second set of data having playback times following the first playback time. 11. Método para enviar dados de mídia, o método caracterizado pelo fato de que compreende: construir (554) uma descrição de instância de sessão de transporte de codificação em camadas (LCT), LSID, incluindo informação representativa de uma pluralidade de sessões LCT, cada uma dentre as sessões LCT incluindo dados de uma representação respectiva dentre uma pluralidade de representações de uma apresentação de mídia de Fluxo Contínuo Adaptável Dinâmico sobre HTTP, DASH, em que a LSID indica correspondências entre as sessões LCT e as representações; emitir (556) a LSID; emitir um primeiro conjunto de dados, incluindo os dados (556) das representações nas sessões LCT correspondentes, até um primeiro tempo de reprodução, antes de emitir um arquivo de manifesto; emitir um arquivo de manifesto após emitir o primeiro conjunto de dados; e emitir um segundo conjunto de dados, diferente do primeiro conjunto de dados, da apresentação de mídia DASH, em resposta aos um ou mais requerimentos com base no arquivo de manifesto, o segundo conjunto de dados tendo tempos de reprodução seguindo o primeiro tempo de reprodução.11. Method for sending media data, the method comprising: constructing (554) a layered coding transport (LCT) session instance description, LSID, including information representative of a plurality of LCT sessions, each of the LCT sessions including data from a respective representation of a plurality of representations of a Dynamic Adaptive Streaming over HTTP, DASH media presentation, wherein the LSID indicates correspondences between the LCT sessions and the representations; issue (556) the LSID; outputting a first set of data, including the data (556) of the representations in the corresponding LCT sessions, up to a first playback time, before outputting a manifest file; emit a manifest file after emitting the first set of data; and outputting a second set of data, different from the first set of data, from the DASH media presentation, in response to the one or more requests based on the manifest file, the second set of data having playback times following the first playback time . 12. Dispositivo (60) para enviar dados de mídia, o dispositivo caracterizado pelo fato de que compreende: meios (62) para construir uma descrição de instância de sessão de transporte de codificação em camadas (LCT), LSID, incluindo informação representativa de uma pluralidade de sessões LCT, cada uma dentre as sessões LCT incluindo dados de uma representação respectiva dentre uma pluralidade de representações de uma apresentação de mídia de Fluxo Contínuo Adaptável Dinâmico sobre HTTP, DASH, em que a LSID indica correspondências entre as sessões LCT e as representações; meios (72) para emitir a LSID; meios (72) para emitir um primeiro conjunto de dados, incluindo os dados das representações nas sessões LCT correspondentes, até um primeiro tempo de reprodução, antes de emitir um arquivo de manifesto, em que os meios (72) para emissão são dispostos para emitir um arquivo de manifesto após emitir o primeiro conjunto de dados; e meios (72) para emitir um segundo conjunto de dados, diferente do primeiro conjunto de dados, da apresentação de mídia DASH, em resposta aos um ou mais requerimentos com base no arquivo de manifesto, o segundo conjunto de dados tendo tempos de reprodução seguindo o primeiro tempo de reprodução.12. Device (60) for sending media data, the device characterized by the fact that it comprises: means (62) for constructing a layered coding transport (LCT) session instance description, LSID, including information representative of a plurality of LCT sessions, each of the LCT sessions including data from a respective representation of a plurality of representations of a Dynamic Adaptive Streaming over HTTP, DASH, media presentation, wherein the LSID indicates correspondences between the LCT sessions and the representations ; means (72) for issuing the LSID; means (72) for outputting a first set of data, including data from representations in corresponding LCT sessions, up to a first playback time, before outputting a manifest file, wherein the means (72) for outputting are arranged to output a manifest file after emitting the first set of data; and means (72) for outputting a second set of data, different from the first set of data, from the DASH media presentation, in response to the one or more requests based on the manifest file, the second set of data having playback times following the first playing time.