BR112020015214A2 - inserção dinâmica de anúncio condicional - Google Patents
inserção dinâmica de anúncio condicional Download PDFInfo
- Publication number
- BR112020015214A2 BR112020015214A2 BR112020015214-5A BR112020015214A BR112020015214A2 BR 112020015214 A2 BR112020015214 A2 BR 112020015214A2 BR 112020015214 A BR112020015214 A BR 112020015214A BR 112020015214 A2 BR112020015214 A2 BR 112020015214A2
- Authority
- BR
- Brazil
- Prior art keywords
- content
- data
- media
- advertisement
- video
- Prior art date
Links
- 238000003780 insertion Methods 0.000 title claims abstract description 24
- 230000037431 insertion Effects 0.000 title claims abstract description 24
- 239000000872 buffer Substances 0.000 claims abstract description 36
- 230000004044 response Effects 0.000 claims abstract description 19
- 238000000034 method Methods 0.000 claims description 64
- 239000012092 media component Substances 0.000 claims description 12
- 238000005192 partition Methods 0.000 claims description 12
- 238000009877 rendering Methods 0.000 claims description 12
- 230000011664 signaling Effects 0.000 claims description 5
- 238000012546 transfer Methods 0.000 claims description 5
- 238000005516 engineering process Methods 0.000 claims description 4
- 230000003068 static effect Effects 0.000 claims description 4
- 238000005070 sampling Methods 0.000 claims description 2
- 101100322030 Drosophila melanogaster Abl gene Proteins 0.000 claims 1
- 230000002265 prevention Effects 0.000 claims 1
- 230000006978 adaptation Effects 0.000 description 50
- 239000012634 fragment Substances 0.000 description 42
- 238000011084 recovery Methods 0.000 description 34
- 230000000875 corresponding effect Effects 0.000 description 27
- 238000005538 encapsulation Methods 0.000 description 21
- 238000010586 diagram Methods 0.000 description 16
- 238000002360 preparation method Methods 0.000 description 15
- 230000002123 temporal effect Effects 0.000 description 13
- 238000012545 processing Methods 0.000 description 12
- 230000005540 biological transmission Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 5
- 238000004891 communication Methods 0.000 description 5
- 230000003287 optical effect Effects 0.000 description 4
- 238000013500 data storage Methods 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000000153 supplemental effect Effects 0.000 description 3
- 230000001052 transient effect Effects 0.000 description 3
- 238000012800 visualization Methods 0.000 description 3
- 102100021786 CMP-N-acetylneuraminate-poly-alpha-2,8-sialyltransferase Human genes 0.000 description 2
- 101000616698 Homo sapiens CMP-N-acetylneuraminate-poly-alpha-2,8-sialyltransferase Proteins 0.000 description 2
- 238000003491 array Methods 0.000 description 2
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 239000000470 constituent Substances 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000010076 replication Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 239000013598 vector Substances 0.000 description 2
- FMYKJLXRRQTBOR-UBFHEZILSA-N (2s)-2-acetamido-4-methyl-n-[4-methyl-1-oxo-1-[[(2s)-1-oxohexan-2-yl]amino]pentan-2-yl]pentanamide Chemical group CCCC[C@@H](C=O)NC(=O)C(CC(C)C)NC(=O)[C@H](CC(C)C)NC(C)=O FMYKJLXRRQTBOR-UBFHEZILSA-N 0.000 description 1
- 240000002791 Brassica napus Species 0.000 description 1
- 101100264654 Enterobacteria phage T4 y12A gene Proteins 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001143 conditioned effect Effects 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 239000013028 medium composition Substances 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000008447 perception Effects 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000008685 targeting Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/81—Monomedia components thereof
- H04N21/812—Monomedia components thereof involving advertisement data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
- H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
- H04N21/43072—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of multiple content streams on the same device
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
- H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
- H04N21/43074—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of additional data with content streams on the same device, e.g. of EPG data or interactive icon with a TV program
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
- H04N21/44016—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for substituting a video clip
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/65—Transmission of management data between client and server
- H04N21/658—Transmission by the client directed to the server
- H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Business, Economics & Management (AREA)
- Marketing (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Information Transfer Between Computers (AREA)
Abstract
inserção dinâmica de anúncio condicional. em um exemplo, um dispositivo para recuperar dados de mídia inclui uma memória configurada para armazenar dados de mídia, incluindo conteúdo de anúncio e dados de mídia principais, e um ou mais processadores implementados em conjunto de circuitos e configurados para: enviar informações de anúncio para um dispositivo servidor de anúncio; receber, em resposta ao envio das informações de anúncio, o conteúdo de anúncio a partir do servidor de anúncio; recuperar os dados de mídia principais; e provisionar o conteúdo de anúncio para os dados de mídia principais. o dispositivo pode adicionalmente incluir um buffer de imagem codificada (cpb) e um decodificador de vídeo que recupera os dados de vídeo codificados a partir do cpb para decodificar. os um ou mais processadores podem provisionar o conteúdo de anúncio para o conteúdo de mídia principal enviando o conteúdo de anúncio e o conteúdo de mídia principal para o cpb.
Description
[0001]Este pedido reivindica o benefício do Pedido Provisório Nº 62/624,603, depositado em 31 de Janeiro de 2018, o Pedido Provisório Norte-Americano Nº 62/633.472, depositado em 21 de Fevereiro de 2018 e o Pedido Norte-Americano Nº 16/262.273, depositado em 30 de Janeiro de 2019, cujo conteúdo total de cada um dos quais é aqui incorporado por referência.
[0002] Esta descrição refere-se a armazenamento e transporte de dados de mídia codificados.
[0003] Os recursos de vídeo digital podem ser incorporados a uma ampla variedade de dispositivos, incluindo televisões digitais, sistemas de difusão direta digital, sistemas de difusão sem fio, assistentes pessoais digitais (PDAs), laptops ou computadores desktop, câmeras digitais, dispositivos de gravação digitais, players de mídia digital, dispositivos de videogame, consoles de videogame, telefones de rádio por satélite ou celular, dispositivos de videoconferência e similares. Os dispositivos de vídeo digitais implementam técnicas de compactação de vídeo, tais como as descritas nos padrões definidos por MPEG-2, MPEG-4, ITU-T H.263 ou ITU-T H.264/MPEG-4, parte 10, Codificação de Vídeo Avançada (AVC), ITU-T H.265 (também referido como Codificação de Vídeo de Alta Eficiência (HEVC)) e extensões desses padrões, para transmitir e receber informações de vídeo digital com mais eficiência.
[0004] Após a codificação dos dados de vídeo, os dados de vídeo podem ser empacotados para transmissão ou armazenamento. Os dados de vídeo podem ser reunidos dentro de um arquivo de vídeo em conformidade com qualquer um dentre uma variedade de padrões, tais como formato de arquivo de mídia com base na Organização Internacional para Padronização (ISO) e suas extensões, tal como AVC.
[0005] Em geral, esta descrição apresenta técnicas para um dispositivo cliente fornecer informações para um servidor de anúncio representando o conteúdo de anúncio que é relevante para o dispositivo cliente. Essa relevância pode corresponder aos dados demográficos de usuário e/ou aos dados de qualidade de anúncio, por exemplo, com base nos recursos de codificação e/ou renderização do dispositivo cliente. Por exemplo, as informações podem indicar qualidades e/ou recursos do conteúdo principal sendo apresentados pelo dispositivo cliente dentro do qual o conteúdo de anúncio deve ser inserido. Dessa maneira, o servidor de anúncio pode enviar o conteúdo de anúncio que corresponde à qualidade do conteúdo principal que está sendo apresentado e que satisfaz os recursos do dispositivo cliente.
[0006] Em um exemplo, um método de recuperação de dados de mídia inclui enviar, por meio de um ou mais processadores implementados em conjunto de circuitos de um dispositivo cliente, informações de anúncio para um dispositivo servidor de anúncio; receber, em resposta ao envio das informações de anúncio, por meio de um ou mais processadores, conteúdo de anúncio a partir do servidor de anúncio; recuperar, por meio de um ou mais processadores,
os dados da mídia principais; e provisionar, por meio de um ou mais processadores, o conteúdo de anúncio para dados da mídia principais.
[0007] Em outro exemplo, um dispositivo para recuperar dados de mídia inclui uma memória configurada para armazenar dados de mídia, incluindo conteúdo de anúncio e dados de mídia principais; e um ou mais processadores implementados em conjunto de circuitos e configurados para: enviar informações de anúncio para um dispositivo servidor de anúncio; em resposta ao envio das informações de anúncio, receber o conteúdo de anúncio a partir do servidor de anúncio; recuperar os dados de mídia principais; e provisionar o conteúdo de anúncio para os dados da mídia principais.
[0008] Em outro exemplo, um meio de armazenamento legível por computador tendo instruções armazenadas que, quando executadas, fazem com que um processador de um dispositivo cliente envie informações de anúncio para um dispositivo servidor de anúncio; em resposta ao envio das informações de anúncio, receba o conteúdo de anúncio a partir do servidor de anúncio; recupere os dados de mídia principais; e provisione o conteúdo de anúncio para os dados de mídia principais.
[0009] Em outro exemplo, um dispositivo para recuperar dados de mídia inclui meios para enviar informações de anúncio para um dispositivo servidor de anúncio; meios para receber, em resposta ao envio das informações de anúncio, conteúdo de anúncio a partir do servidor de anúncio; meios para receber os dados de mídia principais; e meios para provisionar o conteúdo de anúncio para os dados de mídia principais.
[0010] Os detalhes de um ou mais exemplos são apresentados nos desenhos anexos e na descrição abaixo. Outros recursos, objetos e vantagens ficarão evidentes a partir da descrição e dos desenhos, e a partir das reivindicações.
[0011] A FIG. l é um diagrama de blocos ilustrando um sistema de exemplo que implementa técnicas para streaming dados de mídia através de uma rede.
[0012] A FIG. 2 é um diagrama de blocos ilustrando um conjunto de exemplos de componentes de uma unidade de recuperação da FIG. 1 em mais detalhes.
[0013] A FIG. 3 é um diagrama conceitual ilustrando elementos de exemplo de conteúdo multimídia.
[0014] A FIG. 4 é um diagrama de blocos ilustrando elementos de um arquivo de vídeo de exemplo, que pode corresponder a um segmento de uma representação.
[0015] A FIG. 5 é um diagrama conceitual ilustrando exemplos de várias linhas do tempo em DASH e relacionamentos entre as linhas do tempo.
[0016] A FIG. 6 é um diagrama conceitual ilustrando um sistema de exemplo no qual anúncios devem ser inseridos dentro do conteúdo principal.
[0017] A FIG. 7 é um diagrama conceitual ilustrando um sistema de exemplo no qual anúncios devem ser inseridos dentro do conteúdo principal.
[0018] A FIG. 8 é um diagrama de fluxos ilustrando um método de exemplo pelo qual as técnicas desta descrição podem ser realizadas.
[0019] A FIG. 9 é um fluxograma ilustrando um método de exemplo de recuperação de dados de mídia de acordo com as técnicas desta descrição.
[0020] Em geral, esta descrição apresenta técnicas para um dispositivo cliente enviar informações para um servidor de anúncio (ad – advertisement) representando vários tipos de anúncios e/ou conteúdo de anúncio que são relevantes para o dispositivo cliente. Por exemplo, as informações podem indicar que determinados anúncios são mais relevantes para um usuário do dispositivo cliente com base em um ou mais dados demográficos do usuário, bem como formatos para o conteúdo de anúncio, tais como indicações de recursos de codificação e/ou renderização do dispositivo cliente.
[0021] As técnicas desta descrição podem ser aplicadas a arquivos de mídia (por exemplo, vídeo) em conformidade com os dados de vídeo encapsulados de acordo com qualquer formato de arquivo de mídia com base ISO, formato de arquivo de Codificação de Vídeo Escalável (SVC), formato de arquivo de Codificação de Vídeo Avançada (AVC), formato de arquivo do Projeto de Parceria de 3ª Geração (3GPP) e/ou formato de arquivo de Codificação de Vídeo Multivista (MVC) ou outros formatos de arquivos de vídeo similares.
[0022] No streaming HTTP, as operações frequentemente utilizadas incluem HEAD, GET e GET parcial. A operação HEAD recupera um cabeçalho de um arquivo associado com um determinado localizador uniforme de recursos (URL) ou nome uniforme de recursos (URN), sem recuperar uma carga útil associada com o URL ou com o URN. A operação GET recupera um arquivo inteiro associado com um determinado URL ou URN. A operação GET parcial recebe um intervalo de bytes como parâmetro de entrada e recupera um número contínuo de bytes de um arquivo, em que o número de bytes corresponde ao intervalo de bytes recebido. Assim, fragmentos de filme podem ser fornecidos para streaming HTTP, porque uma operação GET parcial pode obter um ou mais fragmentos de filme individuais. Em um fragmento de filme, pode haver vários fragmentos de trilhas (tracks) de diferentes trilhas. No streaming HTTP, uma apresentação de mídia pode ser uma coleção estruturada de dados acessíveis ao cliente. O cliente pode solicitar e baixar informações de dados de mídia para apresentar um serviço de streaming para um usuário.
[0023] No exemplo de streaming de dados 3GPP utilizando o streaming HTTP, podem existir múltiplas representações para dados de vídeo e/ou de áudio de conteúdo multimídia. Conforme explicado abaixo, diferentes representações podem corresponder a diferentes características de codificação (por exemplo, perfis ou níveis diferentes de um padrão de codificação de vídeo), diferentes padrões de codificação ou extensões de padrões de codificação (tais como extensões multivista e/ou escalonáveis) ou taxas de bits diferentes. O manifesto de dessas representações pode ser definido em uma estrutura de dados de Descrição de Apresentação de Mídia (MPD). Uma apresentação de mídia pode corresponder a uma coleção estruturada de dados que é acessível a um dispositivo cliente de streaming HTTP. O dispositivo cliente de streaming HTTP pode solicitar e baixar informações de dados de mídia para apresentar um serviço de streaming para um usuário do dispositivo cliente. Uma apresentação de mídia pode ser descrita na estrutura de dados MPD, que pode incluir atualizações da MPD.
[0024] Uma apresentação de mídia pode conter uma sequência de um ou mais Períodos. Cada período pode se estender até o início do próximo Período, ou até o final da apresentação de mídia, no caso do último período. Cada período pode conter uma ou mais representações para o mesmo conteúdo de mídia. Uma representação pode ser uma dentre um número de versões codificadas alternativas de áudio, vídeo, texto programado (timed text) ou outros desses dados. As representações podem diferir por tipos de codificação, por exemplo, por taxa de bits, resolução e/ou codec para dados de vídeo e taxa de bits, linguagem e/ou codec para dados de áudio. O termo representação pode ser utilizado para se referir a uma seção de dados codificados de áudio ou de vídeo correspondentes a um período particular do conteúdo multimídia e codificados de uma maneira particular.
[0025] As representações de um período particular podem ser atribuídas a um grupo indicado por um atributo na MPD, indicativo de um conjunto de adaptação ao qual as representações pertencem. As representações no mesmo conjunto de adaptação são geralmente consideradas alternativas para cada outra, em que um dispositivo cliente pode comutar dinamicamente e sem interrupção entre essas representações, por exemplo, para realizar a adaptação de largura de banda. Por exemplo, cada representação de dados de vídeo por um período particular pode ser atribuída ao mesmo conjunto de adaptação, de modo que qualquer uma dentre as representações possa ser selecionada para decodificar para apresentar dados de mídia, tais como dados de vídeo ou dados de áudio, de conteúdo multimídia para o período correspondente. O conteúdo de mídia dentro de um período pode ser representado ou por uma representação a partir do grupo 0, se presente, ou pela combinação de no máximo uma representação a partir de cada grupo não zero, em alguns exemplos. Os dados de temporização para cada representação de um período podem ser expressos em relação ao tempo de início do período.
[0026] Uma representação pode incluir um ou mais segmentos. Cada representação pode incluir um segmento de inicialização ou cada segmento de uma representação pode ser auto inicializado. Quando presente, o segmento de inicialização pode conter informações 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 exclusivamente por um identificador, tal como um localizador uniforme de recursos (URL), um nome uniforme de recursos (URN) ou um identificador uniforme de recursos (URI). A MPD pode fornecer os identificadores para cada segmento. Em alguns exemplos, a MPD pode também fornecer intervalos de bytes na forma de um atributo range, que pode corresponder aos dados para um segmento dentro de um arquivo acessível pelo URL, pelo URN ou pelo URI.
[0027] Diferentes representações podem ser selecionadas para recuperação substancialmente simultânea para diferentes tipos de dados de mídia. Por exemplo, um dispositivo cliente pode selecionar uma representação de áudio, uma representação de vídeo e uma representação de texto programado a partir da qual recuperar segmentos. Em alguns exemplos, o dispositivo cliente pode selecionar conjuntos de adaptação particulares para realizar a adaptação de largura de banda. Ou seja, o dispositivo 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 programado. Alternativamente, o dispositivo 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 programado).
[0028] O Formato de Aplicativo de Mídia Comum (CMAF) geralmente é restrito às apresentações do CMAF que cobrem ofertas de conteúdo consistentes. No entanto, em muitos casos, o conteúdo precisa ser oferecido como uma sequência das Apresentações CMAF. Exemplos dessas ofertas incluem: • possibilitar a emenda de conteúdo, por exemplo, para inserção de anúncio (ad) • possibilitar a emenda de conteúdo com diferentes formatos de origem, por exemplo, mudar de 5,1 para estéreo, alterar a taxa de quadros etc. • possibilitar a emenda de conteúdo de diferentes tipos • fornecer sincronização na numeração de segmentos, por exemplo compensar durações de segmento não constantes
• remover ou adicionar certas Trilhas de Representações/CMAF em um conjunto de adaptação/conjunto de comutação • remover ou adicionar certos conjuntos de adaptação/conjunto de comutação • remover ou adicionar conteúdo oferecido em determinados CDNs • ativar a sinalização de segmentos mais curtos, se produzidos por um codificador • por razões de robustez
[0029] Em diversos casos, essas interrupções são relativamente "difíceis", mas em outros casos, o conteúdo é uma continuação do anterior. A continuação pode ser abordada em dois níveis: - continuação semântica (ou seja, o conteúdo contínuo) - continuação para permitir playout adequado (isto é, alterações limitadas nesses pontos de emenda para possibilitar uma saída bem percebida).
[0030] Exemplos práticos para essas questões (a partir de observações de testes heurísticos) incluem: - Reprodução dos destaques dos jogos da Bundesliga. Cada partida é uma "Apresentação" separada, mas através de continuação automática do programa e quando reproduzida através de HDMI, a conexão HDMI é redefinida e a tela fica preta por alguns segundos - Anúncio de pré-rolamento ao se juntar a um serviço ao vivo. Depois que o anúncio de pré-
rolamento é concluído, demora cerca de 1 a 2 segundos até que o programa se junte e o conteúdo fique preto - E muitos mais.
[0031] A FIG. 1 é um diagrama de blocos ilustrando um sistema de exemplo 10 que implementa técnicas para transmitir dados de mídia através de uma rede. Neste exemplo, o sistema 10 inclui o dispositivo de preparação de conteúdo 20, o dispositivo servidor 60 e o dispositivo cliente 40. O dispositivo cliente 40 e o dispositivo servidor 60 são acoplados comunicativamente pela rede 74, que pode compreender a Internet. Em alguns exemplos, o dispositivo de preparação de conteúdo 20 e o dispositivo servidor 60 podem também ser acoplados pela rede 74 ou por outra rede, ou podem ser diretamente acoplados comunicativamente. Em alguns exemplos, o dispositivo de preparação de conteúdo 20 e o dispositivo servidor 60 podem compreender o mesmo dispositivo.
[0032] O dispositivo de preparação de conteúdo 20, no exemplo da FIG. 1, compreende a 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 elétricos representativos dos dados de áudio capturados para serem codificados pelo codificador de áudio 26. Alternativamente, a fonte de áudio 22 pode compreender um meio de armazenamento armazenando dados de áudio gravados previamente, um gerador de dados de áudio tal como um sintetizador computadorizado ou qualquer outra fonte de dados de áudio. A fonte de vídeo 24 pode compreender uma câmera de vídeo que produz dados de vídeo para serem codificados pelo codificador de vídeo 28, um meio de armazenamento codificado com dados de vídeo gravados previamente, 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. O dispositivo de preparação de conteúdo 20 não está necessariamente acoplado de forma comunicativa com o dispositivo servidor 60 em todos os exemplos, mas pode armazenar conteúdo multimídia em um meio separado que é lido pelo dispositivo servidor 60.
[0033] Os dados brutos de áudio e vídeo podem incluir dados analógicos ou digitais. Os dados analógicos podem ser digitalizados antes de serem codificados pelo codificador de áudio 26 e/ou pelo codificador de vídeo 28. A fonte de áudio 22 pode obter dados de áudio a partir de um participante que fala enquanto o participante está falando, e a fonte de vídeo 24 pode obter simultaneamente dados de vídeo do participante que fala. Em outros exemplos, a fonte de áudio 22 pode compreender um meio de armazenamento legível por computador compreendendo dados de áudio armazenados, e a fonte de vídeo 24 pode compreender um meio de armazenamento legível por computador compreendendo dados de vídeo armazenados. Desta maneira, as técnicas apresentadas nesta descrição podem ser aplicadas a dados ao vivo, streaming, áudio e vídeo em tempo real ou a dados de áudio e vídeo pré-gravados e arquivados.
[0034] Os quadros de áudio que correspondem aos quadros de vídeo geralmente são quadros de áudio contendo dados de áudio que foram capturados (ou gerados) pela fonte de áudio 22 simultaneamente com os dados de vídeo capturados (ou gerados) pela fonte de vídeo 24 que estão contidos dentro dos quadros de vídeo. Por exemplo, enquanto um participante que fala geralmente produz dados de áudio falando, a fonte de áudio 22 captura os dados de áudio e a fonte de vídeo 24 captura dados de vídeo do participante que fala ao mesmo tempo, ou seja, enquanto a fonte de áudio 22 captura os dados de áudio. Portanto, um quadro de áudio pode corresponder temporalmente a um ou mais quadros de vídeo particulares. Por conseguinte, um quadro de áudio correspondente a um quadro de vídeo geralmente corresponde a uma situação na qual os dados de áudio e os dados de vídeo foram capturados ao mesmo tempo e para os quais um quadro de áudio e um quadro de vídeo compreendem, respectivamente, os dados de áudio e os dados de vídeo que foram capturados ao mesmo tempo.
[0035] Em alguns exemplos, o codificador de áudio 26 pode codificar uma marca de tempo (timestamp) em cada quadro de áudio codificado que representa um tempo no qual os dados de áudio para o quadro de áudio codificado foram gravados e, similarmente, o codificador de vídeo 28 pode codificar uma marca de tempo em cada quadro de vídeo codificado que representa um tempo no qual os dados de vídeo para o quadro de vídeo codificado foram gravados. Em tais exemplos, um quadro de áudio correspondente a um quadro de vídeo pode compreender um quadro de áudio compreendendo uma marca de tempo e um quadro de vídeo compreendendo a mesma marca de tempo. O dispositivo de preparação de conteúdo 20 pode incluir um clock interno a partir do qual o codificador de áudio 26 e/ou o codificador de vídeo 28 podem gerar as marcas de tempo ou que a fonte de áudio 22 e a fonte de vídeo 24 podem utilizar para associar dados de áudio e de vídeo, respectivamente, com uma marca de tempo.
[0036] Em alguns exemplos, a fonte de áudio 22 pode enviar dados para o codificador de áudio 26 correspondente a um tempo em que os dados de áudio foram gravados, e a fonte de vídeo 24 pode enviar dados para o codificador de vídeo 28 correspondente a um tempo em que os dados de vídeo foram gravados. Em alguns exemplos, o codificador de áudio 26 pode codificar um identificador de sequência nos dados de áudio codificados para indicar uma ordem temporal relativa dos dados de áudio codificados, mas sem necessariamente indicar um tempo absoluto no qual os dados de áudio foram gravados e, similarmente, o codificador de vídeo 28 pode também utilizar identificadores de sequência para indicar uma ordenação temporal relativa dos dados de vídeo codificados. Similarmente, em alguns exemplos, um identificador de sequência pode ser mapeado ou, de alguma forma, correlacionado com uma marca de tempo.
[0037] O codificador de áudio 26 geralmente produz um fluxo de dados de áudio codificado, enquanto o codificador de vídeo 28 produz um fluxo de dados de vídeo codificados. Cada fluxo de dados individual (seja de áudio ou de vídeo) pode ser referido como um fluxo elementar. Um fluxo elementar é um componente único, codificado digitalmente (possivelmente compactado) de uma representação. Por exemplo, a parte de vídeo ou de áudio codificada da representação pode ser um fluxo elementar. Um fluxo elementar pode ser convertido em um fluxo elementar em pacote (PES) antes de ser encapsulado dentro de um arquivo de vídeo. Dentro da mesma representação, um ID de fluxo pode ser utilizado para distinguir os pacotes PES pertencentes a um fluxo elementar do outro. A unidade básica de dados de um fluxo elementar é um pacote de fluxos elementar empacotado (PES). Assim, os dados de vídeo codificados geralmente correspondem a fluxos de vídeo elementares. Similarmente, os dados de áudio correspondem a um ou mais fluxos elementares respectivos.
[0038] Muitos padrões de codificação de vídeo, tais como ITU-T H.264/AVC e o padrão de Codificação de Vídeo de Alta Eficiência (HEVC), definem a sintaxe, a semântica e o processo de decodificação para fluxos de bits livre de erros, qualquer um dos quais está em conformidade com um determinado perfil ou nível. Os padrões de codificação de vídeo normalmente não especificam o codificador, mas o codificador tem a tarefa de garantir que os fluxos de bits gerados sejam compatíveis com o padrão de um decodificador. No contexto dos padrões de codificação de vídeo, um "perfil" corresponde a um subconjunto de algoritmos, recursos ou ferramentas e restrições que se aplicam a eles. Conforme definido pelo padrão H.264, por exemplo, um "perfil" é um subconjunto de toda a sintaxe de fluxo de bits especificada pelo padrão H.264. Um "nível" corresponde às limitações do consumo de recursos do decodificador, tal como, por exemplo, memória e computação do decodificador, relacionadas à resolução das imagens, taxa de bits e taxa de processamento de blocos. Um perfil pode ser sinalizado com um valor de profile_idc (indicador de perfil), enquanto um nível pode ser sinalizado com um valor de level_idc (indicador de nível).
[0039] O padrão 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 obtidos pelos elementos da sintaxe no fluxo de bits, tal como o tamanho especificado das imagens decodificadas. O padrão H.264 reconhece adicionalmente que, em muitas aplicações, não é prático nem econômico implementar um decodificador capaz de lidar com todos os usos hipotéticos da sintaxe em um perfil particular. Consequentemente, o padrão H.264 define um "nível" como um conjunto especificado de restrições impostas aos valores dos elementos da sintaxe no fluxo de bits. Essas restrições podem ser simples limites de valores. Alternativamente, essas restrições podem assumir a forma de restrições nas combinações aritméticas de valores (por exemplo, largura da imagem multiplicada pela altura da imagem multiplicada pelo número de imagens decodificadas por segundo). O padrão H.264 estabelece adicionalmente que implementações individuais podem suportar um nível diferente para cada perfil suportado.
[0040] Um decodificador em conformidade com um perfil normalmente suporta todos os recursos definidos no perfil. Por exemplo, como um recurso de codificação, a codificação de imagem B não é suportada no perfil de base de 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 exija recursos além das limitações definidas no nível. Definições de perfis e níveis podem ser úteis para a interpretabilidade. Por exemplo, durante a transmissão de vídeo, um par de definições de perfil e de nível pode ser negociado e acordado para uma sessão de transmissão inteira. Mais especificamente, no H.264/AVC, um nível pode definir limitações no número de macroblocos que precisam ser processados, no tamanho do buffer de imagem decodificada (DPB), no tamanho do buffer de imagem codificada (CPB), no alcance do vetor de movimento vertical, no número máximo de vetores de movimento por dois MBs consecutivos e se um bloco B pode ter partições de sub- macroblocos menores que 8x8 pixels. Dessa maneira, um decodificador pode determinar se o decodificador é capaz de decodificar adequadamente o fluxo de bits.
[0041] No exemplo da FIG. 1, a unidade de encapsulamento 30 do dispositivo de preparação de conteúdo 20 recebe fluxos elementares compreendendo dados de vídeo codificados a partir do codificador de vídeo 28 e fluxos elementares compreendendo dados de áudio codificados a partir do codificador de áudio 26. Em alguns exemplos, o codificador de vídeo 28 e o codificador de áudio 26 podem incluir empacotadores para a formação de pacotes PES a partir de dados codificados. Em outros exemplos, o codificador de vídeo 28 e o codificador de áudio 26 podem cada um fazer interface com os respectivos empacotadores para formar pacotes PES a partir de dados codificados. Ainda em outros exemplos, a unidade de encapsulamento 30 pode incluir empacotadores para formar pacotes PES a partir de dados de áudio e vídeo codificados.
[0042] O codificador de vídeo 28 pode codificar dados de vídeo de conteúdo multimídia em uma variedade de maneiras, para produzir diferentes representações do conteúdo multimídia em várias taxas de bits e com várias características, tais como resoluções de pixel, taxas de quadros, conformidade com vários padrões de codificação, conformidade com vários perfis e/ou níveis de perfis para vários padrões de codificação, representações tendo uma ou múltiplas visualizações (por exemplo, para reprodução bidimensional ou tridimensional) ou outras características. Uma representação, conforme utilizada nesta descrição, pode compreender dados de áudio, dados de vídeo, dados de texto (por exemplo, para legendas) ou outros dados. A representação pode incluir um fluxo elementar, tal como um fluxo elementar de áudio ou um fluxo elementar de vídeo. Cada pacote PES pode incluir um stream_ID que identifique o fluxo elementar ao qual o pacote PES pertence. A unidade de encapsulamento 30 é responsável pela montagem de fluxos elementares em arquivos de vídeo (por exemplo, segmentos) de várias representações.
[0043] A unidade de encapsulamento 30 recebe pacotes PES para fluxos elementares de uma representação a partir do codificador de áudio 26 e do codificador de vídeo 28 e forma unidades correspondentes de camada de abstração de rede (NAL) a partir dos pacotes PES. Os segmentos de vídeo codificado podem ser organizados em unidades NAL, que fornecem uma representação de vídeo “de rede amigável” abordando aplicações, tais como videotelefonia, armazenamento, transmissão ou streaming. As unidades NAL podem ser categorizadas em unidades NAL de Camada de Codificação de Vídeo (VCL) e unidades NAL não VCL. As unidades VCL podem conter o mecanismo de compactação principal e podem incluir dados em nível de bloco, macrobloco e/ou fatia. Outras unidades NAL podem ser unidades NAL não-VCL. Em alguns exemplos, uma imagem codificada em uma instância de tempo, normalmente apresentada como uma imagem codificada primária, pode estar contida em uma unidade de acesso, que pode incluir uma ou mais unidades NAL.
[0044] As unidades NAL não VCL podem incluir unidades NAL de conjunto de parâmetros e unidades NAL SEI, entre outras. Os conjuntos de parâmetros podem conter informações de cabeçalho em nível de sequência (em conjuntos de parâmetros de sequência (SPS)) e as informações de cabeçalho em nível de imagem que são alteradas com pouca frequência (em conjuntos de parâmetros de imagem (PPS)). Com conjuntos de parâmetros (por exemplo, PPS e SPS), as informações que mudam com pouca frequência não precisam ser repetidas para cada sequência ou imagem, assim, a eficiência de codificação pode ser melhorada. Além disso, a utilização de conjuntos de parâmetros pode permitir a transmissão fora de banda das informações do cabeçalho importantes, evitando a necessidade de transmissões redundantes por resiliência de erros. Em exemplos de transmissão fora da banda, as unidades NAL do conjunto de parâmetros podem ser transmitidas em um canal diferente de outras unidades NAL, tais como as unidades NAL SEI.
[0045] Informações de Aperfeiçoamento Suplementares (SEI) podem conter informações que não são necessárias para decodificar as amostras de imagens codificadas das unidades NAL VCL, mas podem auxiliar nos processos relacionados à decodificação, exibição, resiliência de erros e outros propósitos. As mensagens SEI podem estar contidas em unidades NAL não-VCL. As mensagens SEI são a parte normativa de algumas especificações padrão e, portanto, nem sempre são obrigatórias para a implementação de decodificador compatível com o padrão. As mensagens SEI podem ser mensagens SEI no nível de sequência ou mensagens SEI no nível de imagem. Algumas informações no nível de sequência podem estar contidas nas mensagens SEI, tais como mensagens SEI de informações de escalabilidade no exemplo de SVC e exibir mensagens SEI de informações de escalabilidade em MVC. Essas mensagens SEI de exemplo 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 encapsulamento 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 encapsulamento 30 pode formatar o MPD de acordo com a linguagem de marcação extensível (XML).
[0046] A unidade de encapsulamento 30 pode fornecer dados para uma ou mais representações de conteúdo multimídia, juntamente com o arquivo de manifesto (por exemplo, o MPD) para a interface de saída 32. A interface de saída 32 pode compreender uma interface de rede ou uma interface para gravar em um meio de armazenamento, tal como uma interface de barramento serial universal (USB), um gravador de CD ou DVD, uma interface para mídia de armazenamento magnético ou flash ou outras interfaces para armazenamento ou transmissão de dados de mídia. A unidade de encapsulamento 30 pode fornecer dados de cada uma das representações de conteúdo multimídia para a interface de saída 32, que pode enviar os dados para o dispositivo servidor 60 através de transmissão de rede ou mídia de armazenamento. No exemplo da FIG. 1, o dispositivo 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 66 e uma ou mais representações 68A- 68N (representações 68). Em alguns exemplos, a interface de saída 32 pode também enviar dados diretamente para a rede
74.
[0047] 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 conjuntos de características comuns respectivos, tais como codec, perfil e nível, resolução, número de visualizações, formato de arquivo para segmentos, informações de tipo de texto que podem identificar uma linguagem ou outras características do texto a ser exibido com a representação e/ou dados de áudio para serem decodificados e apresentados, por exemplo, por alto-falantes, informações de ângulo de câmera que podem descrever um ângulo de câmera ou uma perspectiva de câmera no mundo real de uma cena para representações no conjunto de adaptação, informações sobre classificação que descrevem a adequação de conteúdo para audiências particulares ou similares.
[0048] O arquivo de manifesto 66 pode incluir dados indicativos dos subconjuntos das representações 68 correspondentes a conjuntos de adaptação particulares, bem como características comuns para os conjuntos de adaptação.
O arquivo de manifesto 66 pode também incluir dados representativos de características individuais, tais como taxas de bits, para representações individuais de conjuntos de adaptação. Dessa maneira, um conjunto de adaptação pode fornecer uma adaptação simplificada de largura de banda de rede. As representações em um conjunto de adaptação podem ser indicadas utilizando elementos filho de um elemento de conjunto de adaptação do arquivo de manifesto 66.
[0049] O dispositivo servidor 60 inclui a unidade de processamento de solicitação 70 e a interface de rede
72. Em alguns exemplos, o dispositivo servidor 60 pode incluir uma pluralidade de interfaces de rede. Além disso, qualquer um ou todos os recursos do dispositivo servidor 60 podem ser implementados em outros dispositivos de uma rede de entrega de conteúdo, tais como roteadores, pontes, dispositivos proxy, comutadores ou outros dispositivos. Em alguns exemplos, dispositivos intermediários de uma rede de entrega de conteúdo podem armazenar, em cache, dados de conteúdo multimídia 64 e incluir componentes que se ajustam substancialmente aos do dispositivo servidor 60. Em geral, a interface de rede 72 é configurada para enviar e receber dados através da rede 74.
[0050] A unidade de processamento de solicitação 70 é configurada para receber solicitações de rede a partir de dispositivos clientes, tal como o dispositivo cliente 40, para 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, conforme descrito em RFC 2616, “Protocolo de Transferência de Hipertexto - HTTP/1.1”, por R. Fielding et al., Network Working Group, IETF, junho de 1999. Ou seja, a unidade de processamento de solicitação 70 pode ser configurada para receber solicitações GET HTTP ou GET parcial e fornecer dados de conteúdo multimídia 64 em resposta às solicitações. As solicitações podem especificar um segmento de uma dentre as representações 68, por exemplo, utilizando um URL do segmento. Em alguns exemplos, as solicitações podem também especificar um ou mais intervalos de bytes do segmento, assim compreendendo solicitações de GET parcial. A unidade de processamento de solicitações 70 pode ser configurada adicionalmente para atender solicitações de HEAD HTTP para fornecer dados de cabeçalho de um segmento de uma dentre as representações
68. Em qualquer caso, a unidade de processamento de solicitação 70 pode ser configurada para processar as solicitações para fornecer os dados solicitados para um dispositivo solicitante, tal como o dispositivo cliente 40.
[0051] Adicionalmente ou alternativamente, a unidade de processamento de solicitação 70 pode ser configurada para fornecer dados de mídia por meio de um protocolo de difusão ou multidifusão, tal como eMBMS. O dispositivo de preparação de conteúdo 20 pode criar segmentos e/ou subsegmentos DASH substancialmente na mesma maneira conforme descrito, mas o dispositivo servidor 60 pode entregar esses segmentos ou subsegmentos utilizando 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 ingresso no grupo de multidifusão a partir do dispositivo cliente 40. Ou seja, o dispositivo servidor
60 pode anunciar um endereço de protocolo de Internet (IP) associado com um grupo de multidifusão para dispositivos clientes, incluindo o dispositivo cliente 40, associado com um determinado conteúdo de mídia (por exemplo, uma difusão de um evento ao vivo). O dispositivo cliente 40, por sua vez, pode enviar uma solicitação para ingressar no grupo de multidifusão. Esta solicitação pode ser propagada em toda a rede 74, por exemplo, roteadores que compõem a rede 74, de modo que os roteadores sejam direcionados ao tráfego destinado ao endereço IP associado com o grupo de multidifusão para subscrever dispositivos clientes, tais como o dispositivo cliente 40.
[0052] Conforme ilustrado no exemplo da FIG. 1, o conteúdo multimídia 64 inclui o arquivo de manifesto 66, que pode corresponder a uma descrição de apresentação de mídia (MPD). O arquivo de manifesto 66 pode conter descrições de diferentes representações 68 alternativas (por exemplo, serviços de vídeo com diferentes qualidades) e a descrição pode incluir, por exemplo, informações de 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 cliente 40 pode recuperar a MPD de uma apresentação de mídia para determinar como acessar segmentos de representações 68.
[0053] Em particular, a unidade de recuperação 52 pode recuperar dados de configuração (não mostrados) do dispositivo cliente 40 para determinar os recursos de decodificação do decodificador de vídeo 48 e os recursos de renderização da saída de vídeo 44. Os dados de configuração podem também incluir qualquer uma ou todas as preferências de linguagem selecionadas por um usuário do dispositivo cliente 40, uma ou mais perspectivas de câmera correspondentes às preferências de profundidade definidas pelo usuário do dispositivo cliente 40 e/ou uma preferência de classificação selecionada pelo usuário do dispositivo cliente 40. A unidade de recuperação 52 pode compreender, por exemplo, um navegador da web ou um cliente de mídia configurado para enviar solicitações GET HTTP e GET parcial. A unidade de recuperação 52 pode corresponder a instruções de software executadas por um ou mais processadores ou unidades de processamento (não mostrados) do dispositivo cliente 40. Em alguns exemplos, toda ou partes da funcionalidade descrita em relação à unidade de recuperação 52 pode ser implementada em hardware, ou em uma combinação de hardware, software e/ou firmware, em que o hardware necessário pode ser fornecido para executar instruções para software ou firmware.
[0054] A unidade de recuperação 52 pode comparar os recursos de decodificação e renderização do dispositivo cliente 40 com as características das representações 68 indicadas por informações do arquivo de manifesto 66. A unidade de recuperação 52 pode recuperar inicialmente pelo menos uma parte do arquivo de manifesto 66 para determinar as características das representações 68. Por exemplo, a unidade de recuperação 52 pode solicitar uma parte do arquivo de manifesto 66 que descreve 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) tendo características que podem ser satisfeitas pelos recursos de codificação e renderização do dispositivo cliente 40. A unidade de recuperação 52 pode então determinar taxas de bits para representações no conjunto de adaptação, determinar uma quantidade atualmente disponível de largura de banda da rede e recuperar segmentos de uma dentre as representações com uma taxa de bits que pode ser satisfeita pela largura de banda de rede.
[0055] Em geral, representações de taxa de bits mais altas podem produzir uma reprodução de vídeo de qualidade mais alta, enquanto representações de taxa de bits mais baixas podem fornecer reprodução de vídeo de qualidade suficiente quando a largura de banda de rede disponível diminui. Por conseguinte, quando a largura de banda de rede disponível é relativamente alta, a unidade de recuperação 52 pode recuperar dados a partir de representações de taxa de bits relativamente altas, enquanto que quando a largura de banda de rede disponível é baixa, a unidade de recuperação 52 pode recuperar dados a partir de representações de taxa de bits relativamente baixa. Desta maneira, o dispositivo cliente 40 pode transmitir dados de multimídia através da rede 74 enquanto também se adapta à alteração da disponibilidade de largura de banda de rede 74.
[0056] Adicionalmente ou alternativamente, a unidade de recuperação 52 pode ser configurada para receber dados de acordo com um protocolo de rede de difusão ou de multidifusão, tais como eMBMS ou multidifusão IP. Em tais exemplos, a unidade de recuperação 52 pode submeter uma solicitação para ingressar em um grupo de rede de multidifusão associado com um conteúdo de mídia particular.
Depois de ingressar no grupo de multidifusão, a unidade de recuperação 52 pode receber dados do grupo de multidifusão sem solicitações adicionais emitidas para o dispositivo servidor 60 ou para o dispositivo de preparação de conteúdo
20. A unidade de recuperação 52 pode submeter uma solicitação 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 mudar de canal para um grupo de multidifusão diferente.
[0057] A interface de rede 54 pode receber e fornecer dados de segmentos de uma representação selecionada para a unidade de recuperação 52, que por sua vez pode fornecer os segmentos para a unidade de desencapsulamento 50. A unidade de desencapsulamento 50 pode desencapsular elementos de um arquivo de vídeo em fluxos PES constituintes, despachar os fluxos PES para recuperar dados codificados e enviar os dados codificados para o decodificador de áudio 46 ou para o decodificador de vídeo 48, dependendo se os dados codificados fazem parte de um fluxo de áudio ou de vídeo, por exemplo, conforme indicado pelos cabeçalhos de pacotes PES do fluxo.
[0058] Embora não seja expressamente mostrado na FIG. 1, deve ser entendido que um buffer de imagem codificada (CPB), por exemplo, uma memória, pode ser posicionado entre a unidade de desencapsulamento 50 e o decodificador de vídeo 48 para receber dados de vídeo codificados (ou seja, imagens codificadas) para serem decodificados pelo decodificador de vídeo 48. Em alguns exemplos, conforme explicado em mais detalhes abaixo, a unidade de desencapsulamento 50 pode fornecer o conteúdo da mídia principal e o conteúdo do anúncio recebido a partir de diferentes servidores para o decodificador de vídeo 48 através do mesmo CPB. Essa unidade de recuperação 52 pode provisionar o conteúdo de anúncio para o conteúdo da mídia principal e fazer com que o decodificador de vídeo 48 decodifique o conteúdo da mídia principal e o conteúdo de anúncio. O decodificador de áudio 46 decodifica dados de áudio codificados e envia os dados de áudio decodificados para a saída de áudio 42, enquanto o decodificador de vídeo 48 decodifica dados de vídeo codificados e envia os dados de vídeo decodificados, que podem incluir uma pluralidade de visualizações de um fluxo, para a saída de vídeo 44.
[0059] O codificador de vídeo 28, o decodificador de vídeo 48, o codificador de áudio 26, o decodificador de áudio 46, a unidade de encapsulamento 30, a unidade de recuperação 52 e a unidade de desencapsulamento 50, cada um, podem ser implementados como qualquer um dentre uma variedade conjuntos de circuitos de processamento adequados, conforme aplicável, tais como um ou mais microprocessadores, processadores de sinal digital (DSPs), circuitos integrados de aplicação específica (ASICs), arranjos de portas programáveis em campo (FPGAs), conjuntos de circuitos lógicos discretos, software, hardware, firmware ou qualquer combinação dos mesmos. Cada um dos codificadores de vídeo 28 e decodificadores de vídeo 48 pode ser incluído em um ou mais codificadores ou decodificadores, qualquer um dos quais pode ser integrado como parte de um codificador/decodificador de vídeo combinado (CODEC). Da mesma forma, cada um dos codificadores de áudio 26 e decodificadores de áudio 46 pode ser incluído em um ou mais codificadores ou decodificadores, qualquer um dos quais pode ser integrado como parte de um CODEC combinado. Um aparelho incluindo codificador de vídeo 28, decodificador de vídeo 48, codificador de áudio 26, decodificador de áudio 46, unidade de encapsulamento 30, unidade de recuperação 52 e/ou unidade de desencapsulamento 50 pode compreender um circuito integrado, um microprocessador e/ou um dispositivo de comunicação sem fio, tal como um telefone celular.
[0060] O dispositivo cliente 40, o dispositivo 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 descrição. Para propósitos de exemplo, esta descrição apresenta essas técnicas em relação ao dispositivo cliente 40 e ao dispositivo servidor 60. No entanto, deve ser entendido que o dispositivo de preparação de conteúdo 20 pode ser configurado para realizar essas técnicas, em vez de (ou em adição ao) dispositivo servidor
60.
[0061] A unidade de encapsulamento 30 pode formar unidades NAL compreendendo um cabeçalho que identifica um programa ao qual a unidade NAL pertence, bem como uma carga útil, por exemplo, dados de áudio, dados de vídeo ou dados que descrevem o transporte ou o fluxo de programa ao qual a unidade NAL corresponde. Por exemplo, no 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 em 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 encapsulamento 30 pode receber dados de vídeo codificados a partir do codificador de vídeo 28 na forma de pacotes PES de fluxos elementares. A unidade de encapsulamento 30 pode associar cada fluxo elementar com um programa correspondente.
[0062] A unidade de encapsulamento 30 pode também 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, bem como dados de áudio correspondentes ao quadro quando esses dados de áudio estão disponíveis. Uma unidade de acesso geralmente inclui todas as unidades NAL para uma instância de tempo de saída, por exemplo, todos os dados de áudio e vídeo para uma instância de tempo. Por exemplo, se cada exibição tiver uma taxa de quadros de 20 quadros por segundo (fps), cada instância de tempo pode corresponder a um intervalo de tempo de 0,05 segundos. Durante esse intervalo de tempo, os quadros específicos para todas as visualizações da mesma unidade de acesso (a mesma instância de tempo) podem ser renderizados simultaneamente. Em um exemplo, uma unidade de acesso pode compreender uma imagem codificada em uma instância de tempo, que pode ser apresentada como uma imagem codificada primária.
[0063] Por conseguinte, uma unidade de acesso pode compreender todos os quadros de áudio e vídeo de uma instância temporal comum, por exemplo, todas as visualizações correspondentes ao tempo X. Esta descrição refere-se também a uma imagem codificada de uma visualização particular como um “componente de visualização”. Ou seja, um componente de visualização pode compreender uma imagem (ou quadro) codificada para uma visualização particular em um tempo particular. Por conseguinte, uma unidade de acesso pode ser definida como compreendendo todos os componentes de visualização de uma instância temporal comum. A ordem de decodificação das unidades de acesso não precisa necessariamente ser a mesma que a ordem de saída ou de exibição.
[0064] Uma apresentação de mídia pode incluir uma descrição de apresentação de mídia (MPD), que 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, informações de codec, um valor de perfil e um valor de nível. Uma MPD é um exemplo de um arquivo de manifesto, tal como o arquivo de manifesto 66. O dispositivo cliente 40 pode recuperar a MPD de uma apresentação de mídia para determinar como acessar fragmentos de filme de várias apresentações. Os fragmentos de filme podem ser localizados em caixas de fragmentos de filme (caixas moof) de arquivos de vídeo.
[0065] O arquivo de manifesto 66 (que pode compreender, por exemplo, uma MPD) pode anunciar a disponibilidade de segmentos de representações 68. Ou seja, a MPD pode incluir informações indicando o tempo decorrido real (wall-clock time) no qual um primeiro segmento de uma das representações 68 se torna disponível, bem como informações indicando as durações dos segmentos dentro das representações 68. Dessa maneira, a unidade de recuperação
52 do dispositivo cliente 40 pode determinar quando cada segmento está disponível, com base no tempo de início, bem como nas durações dos segmentos que precedem um segmento específico.
[0066] Depois que a unidade de encapsulamento 30 tiver montado unidades NAL e/ou acessar unidades dentro de um arquivo de vídeo com base nos dados recebidos, a unidade de encapsulamento 30 passa o arquivo de vídeo para a interface de saída 32 para emissão. Em alguns exemplos, a unidade de encapsulamento 30 pode armazenar o arquivo de vídeo localmente ou enviar o arquivo de vídeo para um servidor remoto através da interface de saída 32, em vez de enviar o arquivo de vídeo diretamente para o dispositivo cliente 40. A interface de saída 32 pode compreender, por exemplo, um transmissor, um transceptor, um dispositivo para gravar dados em um meio legível por computador, tal como, por exemplo, uma unidade óptica, uma unidade de meio magnético (por exemplo, unidade de disquete), um barramento serial universal (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, tal como, por exemplo, um sinal de transmissão, um meio magnético, um meio óptico, uma memória, um flash drive ou outro meio legível por computador.
[0067] A interface de rede 54 pode receber uma unidade NAL ou uma unidade de acesso através da rede 74 e fornecer a unidade NAL ou a unidade de acesso para a unidade de desencapsulamento 50, através da unidade de recuperação 52. A unidade de desencapsulamento 50 pode desencapsular um elemento de um arquivo de vídeo em fluxos
PES constituintes, desempacotar os fluxos PES para recuperar os dados codificados e enviar os dados codificados para o decodificador de áudio 46 ou para o decodificador de vídeo 48, dependendo se os dados codificados fazem parte de um fluxo de áudio ou de vídeo, por exemplo, conforme indicado pelos cabeçalhos de pacotes PES do fluxo. O decodificador de áudio 46 decodifica dados de áudio codificados e envia os dados de áudio decodificados para a saída de áudio 42, enquanto o decodificador de vídeo 48 decodifica dados de vídeo codificados e envia os dados de vídeo decodificados, que podem incluir uma pluralidade de visualizações de um fluxo, para a saída de vídeo 44.
[0068] A FIG. 2 é um diagrama de blocos ilustrando um conjunto de exemplos de componentes da unidade de recuperação 52 da FIG. 1 em mais detalhes. Neste exemplo, a unidade de recuperação 52 inclui a unidade de middleware eMBMS 100, o cliente DASH 110 e o aplicativo de mídia 112.
[0069] Neste exemplo, a unidade de middleware eMBMS 100 inclui ainda a unidade de recepção eMBMS 106, cache 104 e unidade de servidor proxy 102. Neste exemplo, a unidade de recepção eMBMS 106 está configurada para receber dados através da eMBMS, por exemplo, de acordo com Entrega de Arquivo por Transporte Unidirecional (FLUTE), descrito em T. Paila et al., "FLUTE - Entrega de Arquivo por Transporte Unidirecional", Grupo de Trabalho em Rede, RFC 6726, Novembro de 2012, disponível em http://tools.ietf.org/html/rfc6726. Ou seja, a unidade de recepção eMBMS 106 pode receber arquivos via difusão a partir do, por exemplo, dispositivo servidor 60, que pode atuar como um centro de serviço de difusão/multidifusão (BM-SC).
[0070] Como a unidade de middleware eMBMS 100 recebe dados para arquivos, a unidade de middleware eMBMS pode armazenar os dados recebidos em cache 104. Cache 104 pode compreender um meio de armazenamento legível por computador, tal como memória flash, um disco rígido, RAM ou qualquer outro meio de armazenamento adequado.
[0071] A unidade de servidor proxy 102 pode atuar como um servidor para o cliente DASH 110. Por exemplo, a unidade de servidor proxy 102 pode fornecer um arquivo MPD ou outro arquivo de manifesto ao cliente DASH 110. A unidade de servidor proxy 102 pode anunciar tempos de disponibilidade para segmentos no arquivo MPD, bem como hiperlinks a partir dos quais os segmentos podem ser recuperados. Esses hiperlinks podem incluir um prefixo de endereço de host local correspondente ao dispositivo cliente 40 (por exemplo, 127.0.0.1 para IPv4). Desta maneira, o cliente DASH 110 pode solicitar segmentos a partir da unidade de servidor proxy 102 utilizando solicitações GET HTTP ou GET parcial. Por exemplo, para um segmento disponível no link http: //l27.0.0. l/repl/seg3, o cliente DASH 110 pode construir uma solicitação GET HTTP que inclui uma solicitação para http: //l27.0.0.l/repl/seg3 e submeter a solicitação à unidade de servidor proxy 102. A unidade de servidor proxy 102 pode recuperar dados solicitados a partir de cache 104 e fornecer os dados ao cliente DASH 110 em resposta a esses pedidos.
[0072] A FIG. 3 é um diagrama conceitual ilustrando elementos de exemplo de conteúdo multimídia 120. O conteúdo multimídia 120 pode corresponder ao conteúdo multimídia 64 (FIG. 1) ou outro conteúdo multimídia armazenado no meio de armazenamento 62. No exemplo da FIG. 3, o conteúdo multimídia 120 inclui a descrição de apresentação de mídia (MPD) 122 e uma pluralidade de representações 124A-124N (representações 124). A representação 124A inclui dados de cabeçalho 126 opcionais e segmentos 128A-128N (segmentos 128), enquanto a representação 124N inclui dados de cabeçalho 130 opcionais e segmentos 132A-132N (segmentos 132). A letra N é utilizada para designar o último fragmento de filme em cada uma das representações 124 por uma questão de conveniência. Em alguns exemplos, pode haver um número diferente de fragmentos de filme entre representações 124.
[0073] A MPD 122 pode compreender uma estrutura de dados separada das representações 124. A MPD 122 pode corresponder ao arquivo de manifesto 66 da FIG. 1. Da mesma forma, as representações 124 podem corresponder às representações 68 da FIG. 1. Em geral, a MPD 122 pode incluir dados que geralmente descrevem as características das representações 124, tais como as características de codificação e de renderização, conjuntos de adaptação, um perfil ao qual a MPD 122 corresponde, informações sobre o tipo de texto, informações sobre o ângulo da câmera, informações sobre classificação, informações sobre o “trick mode” (por exemplo, informações indicativas de representações que incluem sub sequências temporais) e/ou informações para recuperar períodos remotos (por exemplo, para inserção direcionada de anúncio dentro do conteúdo da mídia durante a reprodução).
[0074] Os dados do cabeçalho 126, quando presentes, podem descrever características dos segmentos 128, por exemplo, localizações temporais de pontos de acesso aleatórios (RAPs, referidos também como pontos de acesso de fluxo (SAPs)), que dos segmentos 128 incluem pontos de acesso aleatórios, deslocamentos de bytes para pontos de acesso aleatórios dentro dos segmentos 128, localizadores uniformes de recursos (URLs) dos segmentos 128 ou outros aspectos dos segmentos 128. Os dados do cabeçalho 130, quando presentes, podem descrever características similares para os segmentos 132. Adicionalmente ou alternativamente, essas características podem ser totalmente incluídas na MPD 122.
[0075] Os segmentos 128, 132 incluem uma ou mais amostras de vídeo codificado, cada uma das quais pode incluir quadros ou fatias de dados de vídeo. Cada uma das amostras de vídeo codificado dos segmentos 128 pode ter características similares, por exemplo, requisitos de altura, largura e largura de banda. Essas características podem ser descritas pelos dados da MPD 122, embora esses dados não sejam ilustrados no exemplo da FIG. 3. A MPD 122 pode incluir características conforme descritas na Especificação 3GPP, com a adição de alguma ou de todas as informações sinalizadas apresentadas nesta descrição.
[0076] Cada um dos segmentos 128, 132 pode ser associado com um único localizador uniforme de recursos (URL). Assim, cada um dos segmentos 128, 132 pode ser recuperado independentemente utilizando um protocolo de rede de streaming, tal como DASH. Dessa maneira, um dispositivo de destino, tal como o dispositivo cliente 40, pode utilizar uma solicitação GET HTTP para recuperar os segmentos 128 ou 132. Em alguns exemplos, o dispositivo cliente 40 pode utilizar solicitações GET parcial HTTP para recuperar intervalo de bytes específicos dos segmentos 128 ou 132.
[0077] A FIG. 4 é um diagrama de blocos ilustrando elementos de um arquivo de vídeo 150 de exemplo, que pode corresponder a um segmento de uma representação, tal como um dos segmentos 128, 132 da FIG. 3. Cada um dos segmentos 128, 132 pode incluir dados que se ajustam substancialmente à disposição dos dados ilustrados no exemplo da FIG. 4. Pode-se dizer que o arquivo de vídeo 150 encapsula um segmento. Conforme descrito acima, os arquivos de vídeo de acordo com o formato de arquivo de mídia com base em ISO e suas extensões armazenam dados em uma série de objetos, referidos como “caixas”. No exemplo da FIG. 4, o arquivo de vídeo 150 inclui a caixa do tipo de arquivo (FTYP) 152, a caixa de filme (MOOV) 154, as caixas de índice de segmento (sidx) 162, as caixas de fragmento de filme (MOOF) 164 e a caixa de acesso aleatório a fragmentos de filme (MFRA) 166. Embora a FIG. 4 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 programado ou similares) que são estruturados de forma similar aos dados do arquivo de vídeo 150, de acordo com o formato de arquivo de mídia com base em ISO e suas extensões.
[0078] A caixa tipo de arquivo (FTYP) 152 geralmente descreve um tipo de arquivo para o arquivo de vídeo 150. A caixa de tipo de arquivo 152 pode incluir dados que identificam uma especificação que descreve uma melhor utilização para o arquivo de vídeo 150. A caixa de tipo de arquivo 152 pode, alternativamente, ser colocada antes da caixa MOOV 154, das caixas de fragmentos de filme 164 e/ou da caixa MFRA 166.
[0079] Em alguns exemplos, um segmento, tal como o arquivo de vídeo 150, pode incluir uma caixa de atualização de MPD (não mostrada) antes da caixa FTYP 152. A caixa de atualização de MPD pode incluir informações indicando que uma MPD correspondente a uma representação incluindo o arquivo de vídeo 150 deve ser atualizada, juntamente com as informações para atualizar a MPD. Por exemplo, a caixa de atualização de MPD pode fornecer um URI ou um URL para um recurso para ser utilizado para atualizar a MPD. Como outro exemplo, a caixa de atualização de MPD pode incluir dados para atualizar a MPD. Em alguns exemplos, a caixa de atualização de MPD pode seguir imediatamente uma caixa de tipo de segmento (STYP) (não mostrada) do arquivo de vídeo 150, em que a caixa STYP pode definir um tipo de segmento para o arquivo de vídeo 150.
[0080] A caixa MOOV 154, no exemplo da FIG. 4, inclui a caixa de cabeçalho do filme (MVHD) 156, a 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 características gerais do arquivo de vídeo 150. Por exemplo, a caixa MVHD 156 pode incluir dados que descrevem quando o arquivo de vídeo 150 foi criado originalmente, quando o arquivo de vídeo 150 foi modificado pela última vez, uma escala de tempo (timescale) para o arquivo de vídeo 150, uma duração de reprodução do arquivo de vídeo 150 ou outros dados que geralmente descrevem o arquivo de vídeo 150.
[0081] A caixa TRAK 158 pode incluir dados para uma trilha do 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 correspondente à caixa TRAK 158. Em alguns exemplos, a caixa TRAK 158 pode incluir imagens de vídeo codificadas, enquanto em outros exemplos, as imagens de vídeo codificadas da trilha podem ser incluídas nos fragmentos de filme 164, que podem ser referenciados por dados da caixa TRAK 158 e/ou das caixas sidx 162.
[0082] Em alguns exemplos, o arquivo de vídeo 150 pode incluir mais de uma trilha. Por conseguinte, a caixa MOOV 154 pode incluir um número de caixas TRAK iguais ao número de trilhas no arquivo de vídeo 150. A caixa TRAK 158 pode descrever características de uma trilha correspondente do arquivo de vídeo 150. Por exemplo, a caixa TRAK 158 pode descrever informações temporais e/ou espaciais para a trilha correspondente. Uma caixa TRAK similar à caixa TRAK 158 da caixa MOOV 154 pode descrever características de uma trilha de conjunto de parâmetros, quando a unidade de encapsulamento 30 (FIG. 3) inclui uma trilha de conjunto de parâmetros em um arquivo de vídeo, tal como o arquivo de vídeo 150. A unidade de encapsulamento 30 pode sinalizar a presença de mensagens SEI no nível de sequência na trilha de conjunto de parâmetros dentro da caixa TRAK que descreve a trilha de conjunto de parâmetros.
[0083] As caixas MVEX 160 podem descrever as características dos fragmentos de filme 164 correspondentes, por exemplo, para sinalizar que o arquivo de vídeo 150 inclui fragmentos de filme 164, em adição aos dados de vídeo incluídos na caixa MOOV 154, se houver. No contexto de streaming de dados de vídeo, imagens de vídeo codificadas podem ser incluídas nos fragmentos de filme 164 em vez de na caixa MOOV 154. Por conseguinte, todas as amostras de vídeo codificadas podem ser incluídas nos fragmentos de filme 164, em vez de na caixa MOOV 154.
[0084] A caixa MOOV 154 pode incluir um número de caixas MVEX 160 iguais ao número de fragmentos de filme 164 no arquivo de vídeo 150. Cada uma das caixas MVEX 160 pode descrever as características de uma correspondente dos fragmentos de filme 164. Por exemplo, cada caixa MVEX pode incluir uma caixa de caixa de cabeçalho de extensão de filme (MEHD) que descreve uma duração temporal para o correspondente dos fragmentos de filme 164.
[0085] Conforme observado acima, a unidade de encapsulamento 30 pode armazenar um conjunto de dados de sequência em uma amostra de vídeo que não inclui dados de vídeo codificados reais. Uma amostra de vídeo geralmente pode corresponder a uma unidade de acesso, que é uma representação de uma imagem codificada em uma instância de tempo específica. No contexto do AVC, a imagem codificada inclui uma ou mais unidades NAL VCL que contêm as informações para construir todos os pixels da unidade de acesso e outras unidades NAL não-VCL associadas, tais como mensagens SEI. Adequadamente, a unidade de encapsulamento 30 pode incluir um conjunto de dados de sequência, que pode incluir mensagens SEI no nível de sequência, em um dos fragmentos de filme 164. A unidade de encapsulamento 30 pode adicionalmente sinalizar a presença de um conjunto de dados de sequência e/ou mensagens SEI no nível de sequência como estando presentes em um dos fragmentos de filme 164 dentro de uma das caixas MVEX 160 correspondente ao dos fragmentos de filme 164.
[0086] As caixas SIDX 162 são elementos opcionais do arquivo de vídeo 150. Ou seja, os arquivos de vídeo em conformidade com o formato de arquivo 3GPP, ou outros formatos de arquivo, não incluem necessariamente as caixas SIDX 162. De acordo com o exemplo do formato de arquivo 3GPP, uma caixa SIDX pode ser utilizada para identificar um subsegmento de um segmento (por exemplo, um segmento contido no arquivo de vídeo 150). O formato de arquivo 3GPP define um subsegmento como “um conjunto autocontido de uma ou mais caixas de fragmentos de filmes consecutivos com a(s) caixa(s) de Dados de Mídia correspondentes e uma Caixa de Dados de Mídia contendo dados referenciados por uma Caixa de Fragmento de Filme deve seguir 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 do arquivo 3GPP indica também que uma caixa SIDX “contém uma sequência de referências a subsegmentos do (sub)segmento documentado pela caixa. Os subsegmentos referenciados são contíguos no tempo de apresentação. Da mesma forma, os bytes referidos por uma caixa de índice de segmento são sempre contíguos no segmento. O tamanho referenciado fornece a contagem do número de bytes no material referenciado”.
[0087] As caixas SIDX 162 geralmente fornecem informações representativas de um ou mais subsegmentos de um segmento incluído no arquivo de vídeo 150. Por exemplo, essas informações podem incluir tempos de reprodução nos quais os subsegmentos começam e/ou terminam, deslocamentos de bytes para os subsegmentos, se os subsegmentos incluírem (por exemplo, começam com) um ponto de acesso de fluxo (SAP), um tipo para o SAP (por exemplo, se o SAP é uma imagem de atualização instantânea do decodificador (IDR), uma imagem limpa de acesso aleatório (CRA), uma imagem de acesso a link quebrado (BLA) ou similares), uma posição do SAP (em termos de tempo de reprodução e/ou deslocamento de bytes) no subsegmento e similares.
[0088] Os fragmentos de filme 164 podem incluir uma ou mais imagens de vídeo codificadas. Em alguns exemplos, os fragmentos de filme 164 podem incluir um ou mais grupos de imagens (GOPs), cada um dos quais pode incluir um número de imagens de vídeo codificadas, por exemplo, quadros ou imagens. Adicionalmente, conforme descrito acima, os fragmentos de filme 164 podem incluir conjuntos de dados de sequência em alguns exemplos. Cada um dos fragmentos de filme 164 pode incluir uma caixa de cabeçalho de fragmento de filme (MFHD, não mostrada na FIG. 4). A caixa MFHD pode descrever as características do fragmento de filme correspondente, tal como um número de sequência para o fragmento de filme. Os fragmentos de filme 164 podem ser incluídos na ordem de número de sequência no arquivo de vídeo 150.
[0089] A caixa MFRA 166 pode descrever pontos de acesso aleatórios dentro de fragmentos de filme 164 do arquivo de vídeo 150. Isto pode ajudar na realização de “trick mode”, tal como realizar buscas em 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ída em arquivos de vídeo, em alguns exemplos. Da mesma forma, um dispositivo cliente, tal como o dispositivo cliente 40, não precisa necessariamente fazer referência à caixa MFRA 166 para decodificar e exibir corretamente os dados de vídeo do arquivo de vídeo 150. A caixa MFRA 166 pode incluir um número de caixas de acesso aleatório ao fragmento de trilha (TFRA) (não mostrado) igual ao número de trilhas do arquivo de vídeo 150 ou, em alguns exemplos, igual ao número de trilhas de mídia (por exemplo, trilhas não indicativas) do arquivo de vídeo 150.
[0090] Em alguns exemplos, os fragmentos de filme 164 podem incluir um ou mais pontos de acesso de fluxo (SAPs), tais como imagens IDR. Da mesma forma, a caixa MFRA 166 pode fornecer indicações de localizações dentro do arquivo de vídeo 150 dos SAPs. Por conseguinte, uma subsequência temporal do arquivo de vídeo 150 pode ser formada a partir de SAPs do arquivo de vídeo 150. A subsequência temporal pode também incluir outras figuras, tais como quadros P e/ou quadros B que dependem dos SAPs. Os quadros e/ou as fatias da subsequência temporal podem ser dispostos dentro dos segmentos, de modo que os quadros/fatias da subsequência temporal que dependem de outros quadros/fatias da subsequência possam ser decodificados adequadamente. Por exemplo, na disposição hierárquica de dados, os dados utilizados para predição para outros dados podem também ser incluídos na subsequência temporal.
[0091] A FIG. 5 é um diagrama conceitual ilustrando exemplos de várias linhas do tempo em DASH e relacionamentos entre as linhas do tempo. A FIG. 5 representa três Períodos de exemplo, cada um dos Períodos contendo múltiplas Representações. Para a discussão das técnicas desta descrição, é irrelevante se essas Representações estão incluídas no mesmo conjunto de adaptação ou em diferentes conjuntos de adaptação.
[0092] As informações a seguir podem estar disponíveis na MPD (ou outro arquivo de manifesto) relacionado à temporização: • MPD@AvailabilityStartTime: o tempo de início é a âncora da MPD no tempo decorrido real. Este valor é indicado como "AST" na FIG. 5, para “disponibilidade de tempo de início”. • Period@start: o tempo de início do período em relação ao tempo de início de disponibilidade de MPD. Este valor é indicado como "PST" na FIG. 5, para “tempo de início de período”. • Representation@presentationTimeOffset: o deslocamento do tempo de apresentação da Representação no Período, ou seja, fornece o tempo de mídia da Representação que deve ser renderizada no início do Período. Normalmente, esse tempo é o primeiro tempo de apresentação do primeiro segmento ou um valor um pouco maior, para garantir a sincronização de diferentes componentes de mídia. Se maior, esta
Representação é apresentada com um pequeno atraso em relação ao início de Período. Este valor é indicado como "PTO" na FIG. 5, para “deslocamento de tempo de apresentação.”
[0093] Além disso, com a utilização da Representation@duration ou Representation.SegmentTimeline, o tempo de início da MPD para cada segmento e a duração da MPD para cada segmento podem ser derivados. Para detalhes, consulte ISO/IEC 23009-1 e a discussão abaixo.
[0094] De acordo com a FIG. 5, o AST é um tempo decorrido real. Neste exemplo, o AST fornece uma âncora para a computação de todo tempo decorrido rela na MPD. A soma do Period@start do primeiro Período e do AST fornece o valor PST1 doa tempos de início de Período no tempo decorrido real do primeiro Período.
[0095] A origem da linha do tempo de mídia para trilhas nos arquivos de Formato de Mídia com Base em ISO é definida como zero. Cada Representação recebe um deslocamento de tempo de apresentação, pelo valor do atributo Representation@presentationTimeOffset ou, por padrão, definido como 0. O valor desse atributo é indicado como "PTO". Normalmente, para arquivos completos sequenciados como Períodos, esse valor é 0. Para arquivos "parciais" ou transmissões ao vivo, @presentationTimeOffset indica o tempo de composição/apresentação de mídia das amostras que são sincronizadas com o início do Período. @presentationTimeOffset para a transmissão ao vivo geralmente não será zero, porque os codificadores geralmente são iniciados antes de disponibilidade da apresentação, para que as estampas de tempo de mídia nos primeiros segmentos disponíveis aumentem desde que os codificadores foram iniciados. As estampas de tempo de codificação podem ser definidas como Tempo Universal Coordenado (UTC) (como se o codificador tivesse sido ativado em 1/1/1970 à meia-noite). Representações em Períodos de conteúdo ao vivo geralmente têm o mesmo @presentationTimeOffset desde que a mídia seja codificada continuamente, porque o tempo UTC e o tempo de mídia aumentam na mesma taxa e mantêm o mesmo deslocamento.
[0096] Certas considerações, conforme discutidas abaixo, são relevantes para DASH, com referência às diretrizes de DASH-IF IOP e à Emenda 3 (Alt.3) de MPEG- DASH. Em certas circunstâncias, a Apresentação de Mídia é oferecida, de tal modo que o próximo Período seja uma continuação do conteúdo no Período anterior, possivelmente no Período imediatamente seguinte ou em um Período posterior (por exemplo, após a inserção de um Período de anúncio), em particular esses certos componentes de mídia são continuados.
[0097] O fornecedor de conteúdo (por exemplo, dispositivo de preparação de conteúdo 20 da FIG. 1) pode expressar que os componentes de mídia contidos em dois Conjuntos de Adaptação em dois Períodos diferentes são associados atribuindo Identificadores de Assets equivalentes a ambos os Períodos e identificando os Conjuntos de Adaptação com valor idêntico para o atributo @id. A associação expressa uma continuação lógica do componente de mídia no próximo Período e pode, por exemplo, ser utilizada pelo cliente para continuar reproduzindo um Conjunto de Adaptação associado no novo Período.
[0098] Além disso, DASH define dois Conjuntos Adaptação em uma MPD como sendo contínuos por período, se todos os itens a seguir forem válidos: • Os Conjuntos de Adaptação são associados. • A soma do valor de @presentationTimeOffset e a duração da apresentação de todas as Representações em um Conjunto de Adaptação é idêntica ao valor do @presentationTimeOffset do Conjunto de Adaptação associado no próximo Período. • Se as Representações nos dois Conjuntos de Adaptação tiverem o mesmo valor para @id, então elas deverão ter Segmentos de Inicialização funcionalmente equivalentes, ou seja, o Segmento de Inicialização poderá ser utilizado para continuar o play-out da Representação.
A concatenação do Segmento de Inicialização do primeiro Período, se presente, e todos os Segmentos de Mídia consecutivos na Representação no primeiro Período e subsequentemente a concatenação com todos os Segmentos de Mídia consecutivos na Representação do segundo Período representará uma sequência de Segmentos em conformidade, conforme definido em 4.5.4, em conformidade com o tipo de mídia, conforme especificado no atributo @mimeType para a Representação no primeiro Período.
Além disso, o atributo @mimeType para a Representação no próximo Período deve ser o mesmo que o do primeiro
Período.
[0099] As Apresentações de Mídia devem sinalizar Conjuntos de Adaptação contínuos por período utilizando um descritor suplementar no nível de Conjunto de Adaptação com @schemeIdUri definido como "Urn:mpeg:dash:períod- continuity:2015" com: • o @value do descritor correspondendo ao valor de um @id de um Período contido na MPD, • o valor do AdaptationSet@id sendo o mesmo nos dois Períodos.
[0100] A MPD deve sinalizar Conjuntos de Adaptação contínuos por período se a MPD contiver Períodos com Identificadores de Assets idênticos.
[0101] Existem casos especiais, nos quais a mídia em um Conjunto de Adaptação é uma continuação do Conjunto de Adaptação anterior, mas as estampas de tempo não são contínuas. Exemplos são marca de tempo envolvida, reinicialização de codificador, emenda ou outros aspectos. Dois Conjuntos de Adaptação em uma MPD são conectados por período, por DASH, se todas as condições a partir da continuidade do período acima forem mantidas, exceto que as estampas de tempo nos limites de Período podem ser não contínuas, mas ajustadas pelo valor do @presentationTimeOffset no limite de Período. No entanto, por exemplo, o Segmento de Inicialização pode ser equivalente nos dois Conjuntos de Adaptação. As Apresentações de Mídia devem sinalizar Conjuntos de Adaptação conectados com o período utilizando um descritor suplementar no nível de Conjunto de Adaptação com @schemeIdUri definido como
“urn:mpeg:dash:periodconnectivity:20l5.”
[0102] A continuidade do período pode implicar em conectividade de período.
[0103] Autores de conteúdo em DASH são encorajados a oferecer conteúdo como sinalização de período contínuo ou período conectado, se o conteúdo seguir as regras. O cliente deve explorar esses sinais para obter uma experiência perfeita de usuário através dos limites de Período.
[0104] DASH não aborda o caso de segmento de comutação de fluxo de bits/inicialização única. No entanto, se os Segmentos de Inicialização forem os mesmos através dos limites de Período, a reinicialização obviamente não será necessária. O Segmento de Inicialização (Init) Idêntica pode ser facilmente detectado pelos Segmentos de Inicialização com URLs idênticos.
[0105] DASH também não fornece quaisquer garantias ou promessas de Período Cruzado (Cross-Period) para conectividade e para a continuidade de período, pois sempre foi considerado que o conteúdo pode ser reproduzido independentemente desse recurso, possivelmente apenas com alguma qualidade reduzida.
[0106] A continuidade e a conectividade de período foram desenvolvidas para DVB DASH inicialmente devido a discussões sobre inserção de ad. Sua aplicação foi encontrada em DASH-IF e DVB, e o conteúdo de teste está disponível.
[0107] Segmento de Inicialização Única, Continuidade de Período e Conectividade de Período podem ser utilizados para a reprodução simplificada de cliente.
Em um modo DASH geral, no limite de período, um cliente DASH normalmente seleciona um Conjunto de Adaptação de áudio e um Conjunto de Adaptação de vídeo, possivelmente uma trilha de subtítulo também. No limite de Período, uma reinicialização completa pode ocorrer da seguinte maneira: 1) O cliente DASH remove o buffer de origem do Período antigo 2) O cliente DASH cria um novo buffer de origem com o mesmo mimeType 3) O cliente DASH anexa o Segmento de Inicialização 4) O cliente DASH anexa o primeiro Segmento de Mídia.
[0108] A reinicialização do buffer de origem pode causar problemas significativos. No entanto, se o conteúdo for gerado com continuidade e conectividade de período, então não será necessário reduzir o buffer de origem. Em vez disso, o cliente DASH pode utilizar o mesmo buffer de origem, da seguinte maneira: 1) Se a continuidade ou a conectividade de Período for sinalizada, o buffer de origem será mantido. 2) Se o Segmento de Inicialização for o mesmo nos dois Períodos para o segmento continuar, o Segmento Init não será adicionado ao buffer de origem. 3) Se a continuidade de Período for sinalizada, então o primeiro segmento de mídia do novo Período será anexado ao buffer de origem. 4) Se a Conectividade de Período for sinalizada,
então o primeiro segmento de mídia do novo Período será anexado ao buffer de origem. Ao mesmo tempo, o deslocamento de tempo de apresentação será utilizado para ajustar a temporização de playout do buffer de origem para garantir a reprodução contínua.
[0109] Em DASH, os Conjuntos de Adaptação são contínuos, ou seja, o problema é tratado por componente de mídia. Isto significa também que tudo o que permite a comutação sem interrupção em um Conjunto de Adaptação ao longo de Representações também é idêntico nos limites de Período. Portanto, as restrições ao longo de Períodos são herdadas diretamente.
[0110] Geralmente, o CMAF se beneficiaria de um conceito semelhante, seguindo a discussão em CTA WAVE (Ecossistema de Vídeo de Aplicativo da Web da Associação de Tecnologia do Consumidor) como exemplo, mas também para o mapeamento do conteúdo CMAF para DASH. Dois aspectos podem ser abordados: 1) Continuidade/conectividade de Conjunto de Trilha e Comutação através das Apresentações CMAF. 2) Perfis para sequências de apresentações CMAF que atendem a certos requisitos no limite.
[0111] O último aspecto pode ser adiado para mais tarde ou pode ser tratado por aplicativos de CMAF. O foco em CMAF deve estar no primeiro aspecto acima.
[0112] Com relação à continuidade/conectividade de conjunto de Trilha e Comutação nas apresentações CMAF, três opções de exemplo incluem:
1) Cada perfil de mídia define os requisitos de continuidade/conectividade para si mesmo. 2) Por perfis de mídia bem definidos e restrições de Conjunto de Comutação, o conceito de continuidade/conectividade é herdado diretamente a partir das definições. 3) Por padrão, a herança é concluída, mas os perfis de mídia podem restringir ainda mais a conectividade de Conjunto de Comutação.
[0113] Utilizar a herança, mas permitir que os perfis de mídia restrinjam a conectividade de Conjunto de Comutação, pode ser adequado, pois resulta em alterações mínimas para a especificação CMAF existente, mas deixa espaço e oportunidades para considerações adicionais para cada perfil de mídia.
[0114] Esta descrição reconhece um potencial problema inerente na especificação CMAF: Todas as trilhas CMAF em uma apresentação CMAF contendo um conjunto de comutação de vídeo devem começar alinhadas com o tempo zero da apresentação CMAF igual ao tempo inicial da apresentação da amostra de mídia de vídeo mais antiga no fragmento CMAF mais antigo, ver Apresentação de CMAF 6.6.8 e Modelo de Temporização. Isso significa que uma apresentação de acompanhamento de CMAF não pode ter tempo de apresentação zero, pois isso resultaria em uma descontinuidade nos tempos de apresentação.
[0115] Esta é uma restrição excessiva em CMAF. DASH permite Períodos que começam com tempos de apresentação diferentes de 0 (e podem ser compensados com o presentationTimeOffset), mas CMAF proíbe o tempo de início diferente de zero. Portanto, os programas WAVE de linha de base não podem ser construídos. As técnicas desta descrição podem ser utilizadas para corrigir esse problema. Em particular, a seguinte cláusula pode ser adicionada ao CMAF como uma atualização:
7.3.7 Apresentação de Conjuntos de Comutação através dos Limites de Apresentação Em muitos casos, o conteúdo precisa ser oferecido como uma sequência de Apresentações CMAF. Exemplos dessas ofertas são: • habilitar a emenda de conteúdo, por exemplo, inserção de ad, • habilitar a emenda de conteúdo com diferentes formatos de fonte, por exemplo, alternar a partir de 5.1 para estéreo, alterar a taxa de quadros etc. • remover ou adicionar certas Trilhas de Representações/CMAF em um Conjunto de Adaptação/Conjunto de Comutação, • remover ou adicionar certos Conjuntos de Adaptação/Conjuntos de Comutação, • por razões de robustez.
[0116] Embora, em geral, a apresentação contínua de um tipo de mídia específico através dos limites da Apresentação CMAF possa ser difícil, se o conteúdo for preparado adequadamente, a reprodução do tipo de mídia em um Conjunto de Comutação em uma Apresentação CMAF pode ser gerada de modo que possa ser reproduzida sem problemas como uma continuação de um Conjunto de Comutação em outra/anterior Apresentação CMAF através desses limites.
[0117] O fornecedor de conteúdo pode expressar que os componentes de mídia contidos nos Conjuntos de Comutação em uma Apresentação CMAF estão conectados com um Conjunto de Comutação em uma outra/anterior Apresentação CMAF. A Conectividade de Conjunto de Comutação CMAF pode ser sinalizada, se e somente se o Conjunto de Comutação em uma Apresentação CMAF seguinte tiver as seguintes propriedades: • Todas as Trilhas CMAF no Conjunto de Comutação na Apresentação CMAF seguinte deve ter um Cabeçalho CMAF que pode estar também presente no Conjunto de Comutação da Apresentação CMAF anterior. • Todos os parâmetros de codificação das Trilhas CMAF no Conjunto de Comutação na Apresentação CMAF seguinte devem ser tais que cumpram as restrições de Conjunto de Comutação no Conjunto de Comutação da Apresentação CMAF anterior. • Atende às restrições de perfil de mídia para os Conjuntos de Comutação Conectados, se o perfil de mídia definir restrições adicionais.
[0118] Nenhuma sinalização explícita é definida em CMAF para este propósito, mas é deixada para se manifestar a fim de instruir os players a suportarem esse playout.
[0119] O fornecedor de conteúdo pode expressar que os componentes de mídia contidos nos Conjuntos de Comutação em uma outra/anterior Apresentação CMAF são contínuos para um Conjunto de Comutação em uma Apresentação CMAF anterior. A Continuidade de Conjunto de Comutação pode ser sinalizada, se o Conjunto de Comutação em uma Apresentação CMAF seguinte tiver as seguintes propriedades: • Os Conjuntos de Comutação devem estar conectados. • A soma do primeiro tempo de apresentação de uma trilha CMAF e a duração da trilha CMAF de todas as trilhas em um Conjunto de Comutação em um CMAF anterior são idênticas ao primeiro tempo de apresentação de uma trilha CMAF na Apresentação CMAF seguinte.
[0120] Em casos específicos, os dois Conjuntos de Comutação podem também compartilhar um cabeçalho CMAF comum.
[0121] Em um modelo de reprodução hipotético além dos limites de Apresentação CMAF, em um modelo de reprodução hipotético, um player normalmente seleciona um Conjunto de Comutação CMAF de áudio e um de vídeo e, possivelmente, um para subtítulos também. No limite de Apresentação, uma reinicialização completa aconteceria da seguinte maneira: 1) O player reduz o buffer de origem para cada tipo de mídia da Apresentação CMAF anterior 2) O player cria um novo buffer de origem para cada conjunto de comutação da nova Apresentação CMAF 3) Para cada tipo de mídia, a. o player anexa o cabeçalho CMAF b. O player anexa o primeiro Fragmento CMAF e possivelmente define a temporização para o tempo de apresentação do primeiro tempo de apresentação sinalizado.
[0122] A reinicialização do buffer de origem pode causar problemas significativos na percepção de reprodução contínua, pois os pipelines de mídia podem ser reinicializados.
[0123] O Segmento de Inicialização Única, a Continuidade de Conjunto de Comutação CMAF e a Conectividade de Conjunto de Comutação CMAF podem ser utilizados para a reprodução simplificada de cliente. Em um modelo de reprodução hipotético através dos limites de Apresentação CMAF, um cliente de aplicativo pode fazer uso dessa sinalização da seguinte maneira: 1) Se a Conectividade ou Continuidade de Conjunto de Comutação forem sinalizadas, o buffer de origem será mantido. 2) Se o Cabeçalho CMAF for o mesmo nas duas Apresentações CMAF para as duas trilhas a serem reproduzidas, o Cabeçalho CMAF não será adicionado ao buffer de origem. 3) Se a Continuidade do Conjunto de Comutação for sinalizada, o primeiro Fragmento CMAF da nova Apresentação será anexado ao buffer de origem. 4) Se a Conectividade do Conjunto de Comutação for sinalizada, o primeiro Fragmento CMAF da nova Apresentação será anexado ao buffer de origem e o deslocamento de tempo de apresentação será utilizado para ajustar a temporização de playout do buffer de origem para garantir a reprodução contínua.
[0124] Várias atividades podem abordar a questão da reprodução contínua de conteúdo quando um ad é inserido no dispositivo cliente 40, no servidor 60 ou em outros dispositivos. Exemplos incluem: • CTA WAVE aborda restrições de programa e de dispositivo para inserção de ad • MPEG CMAF aborda os principais capacitadores • Força-tarefa de inserção de anúncios DASH-IF para DASH-IF IOP • Inserção de ad direcionados a DVB desenvolve requisitos comerciais.
[0125] A FIG. 6 é um diagrama conceitual ilustrando um sistema de exemplo 250 no qual anúncios devem ser inseridos no conteúdo principal. O sistema 250 inclui o servidor de anúncio ("ad") 254, o servidor de conteúdo principal 252 e o gerador de manifesto 256. Em alguns casos, a funcionalidade atribuída ao servidor ad 254, ao servidor de conteúdo principal 252 e ao gerador de manifesto 256 pode ser incorporada em um único dispositivo. No entanto, no exemplo da FIG. 6, dispositivos servidores separados, conforme mostrado, realizam essa funcionalidade. Em particular, o servidor ad 254 fornece segmentos de inserção de ad 260 ao dispositivo restrito 258, o servidor de conteúdo principal 252 fornece segmentos de conteúdo principal 262 ao dispositivo restrito 258 e o gerador de manifesto 256 fornece arquivo de manifesto 264 (por exemplo, uma MPD) ao dispositivo restrito 258.
[0126] Em muitos casos, o conteúdo de ad é fornecido em uma biblioteca separada e independente do conteúdo principal. Embora ads possam geralmente ser considerados "irritantes" para os usuários, há um benefício significativo se a qualidade dos ads corresponder a alguns ou todos os seguintes itens:
1. A qualidade do ad sendo correspondente aos recursos do dispositivo cliente (por exemplo, recursos de decodificação e/ou renderização).
2. Recurso(s) do ad, por exemplo, se a interatividade é suportada ou não.
3. A qualidade do ad sendo correspondente ao conteúdo principal atualmente em reprodução. Por exemplo, evitando quaisquer redefinições de HDMI, reinicialização do buffer de origem, quadros em preto desnecessários devido a emenda de conteúdo, criptografia e incompatibilidade de conteúdo protegido, configurações diferentes de codec de áudio etc. Isso pode ser aperfeiçoado ainda mais com a combinação do conteúdo reproduzido e dos recursos do dispositivo. Por exemplo, para certos recursos, o desempenho de ad pode ser aperfeiçoado.
4. Os requisitos de codificação (temporização, emenda) do ad no ponto de emenda de ad.
5. A personalização do ad para o usuário, por exemplo, com base em ids de usuários, geolocalização e assim por diante.
6. A duração da partição de ad.
7. Outros problemas que permitem direcionar o anúncio.
[0127] As técnicas convencionais não têm, especialmente, enfatizado a terceira questão de casar a qualidade dos ads com o conteúdo principal sendo atualmente largamente reproduzido até hoje, porque muitos fluxos de trabalho são bastante verticais e os fornecedores de conteúdo também condicionam seus anúncios. No entanto, com mais e mais formatos de conteúdo, recursos de dispositivo e formatos diferentes, existe um benefício em combinar os itens acima de forma consistente e fornecer ao servidor de anúncio o máximo de informações possível, a fim de fornecer um "bom" ad emendado.
[0128] O ad pode também incluir dados que fornecem instruções sobre as condições do ad, para que a reprodução otimize a experiência de usuário utilizando instruções de reprodução adequadas.
[0129] Outro aspecto adicional é a questão de o receptor poder adicionar dois SourceBuffers (elementos de decodificação de mídia), um para reprodução de ad e outro para o conteúdo principal.
[0130] A FIG. 7 é um diagrama conceitual ilustrando um sistema 280 de exemplo no qual anúncios devem ser inseridos no conteúdo principal. O sistema 280 inclui o servidor de anúncio ("ad") 284, o servidor de conteúdo principal 282 e o gerador de manifesto 286. Em alguns casos, a funcionalidade atribuída ao servidor ad 284, ao servidor de conteúdo principal 282 e ao gerador de manifesto 286 pode ser incorporada em um único dispositivo. No entanto, no exemplo da FIG. 7, dispositivos servidores separados, conforme mostrado, realizam essa funcionalidade. Em particular, o servidor ad 284 fornece segmentos de inserção de ad 298 para o dispositivo restrito 288, o servidor de conteúdo principal 282 fornece segmentos do conteúdo principal 290 para o dispositivo restrito 288 e o gerador de manifesto 286 fornece o arquivo de manifesto 292 (por exemplo, uma MPD) par o dispositivo restrito 288.
[0131] De acordo com as técnicas desta descrição, o dispositivo restrito 288 (que pode representar um dispositivo cliente, tal como o dispositivo cliente 40 da FIG. 1) envia as informações requisitadas 294 condicionadas para o servidor ad 284. O servidor ad 284 utiliza essas informações para fornecer conteúdo de ad para o dispositivo restrito 288. Em particular, o servidor ad 284 pode play out o conteúdo de ad de uma maneira adequada e ajustada. Isto inclui que o dispositivo restrito 288 pode provisionar o conteúdo de ad para o conteúdo principal para ser exibido dentro de um buffer de origem, tal como um buffer de imagem codificada (CPB) de um decodificador de vídeo. Em particular, o conteúdo de ad que o servidor ad 284 fornece inclui um arquivo de submanifesto 296 direcionado e segmentos de inserção de ad 298. Uma questão importante é que o servidor ad 284 pode ter informações suficientes sobre os recursos (por exemplo, recursos de decodificação e/ou renderização) do dispositivo restrito 288, bem como sobre o conteúdo atualmente sendo reproduzido pelo dispositivo restrito 288. Com base nessas informações, o servidor ad 284 pode preparar e fornecer adequadamente o conteúdo para que a reprodução seja contínua.
[0132] Como um exemplo, o dispositivo restrito 288 pode fornecer qualquer uma dentre as seguintes informações, isoladamente ou em qualquer combinação, para o servidor ad 284: 1) Os recursos do dispositivo restrito 288, por exemplo, como a inserção de ad pode ser manipulada. Algumas opções de exemplo incluem: a. Buffer de origem único com inicialização estática. b. Propriedades HDMI c. Múltiplos buffers de origem d. Operação regular de extensões de fonte de mídia (MSE) 2) A partição de tempo de inserção de ad. Isto permite que o servidor ad 284 selecione com precisão o ad e os limites de ad. 3) As propriedades do conteúdo reproduzido, por exemplo, Cabeçalho CMAF do conteúdo reproduzido de cada componente de mídia. Isto permite que o servidor ad 284 selecione o conteúdo de adequado que corresponda à reprodução. 4) A última temporização reproduzida do conteúdo principal de cada componente de mídia. Isto permite que o servidor ad 284 emende o conteúdo de adequadamente, por exemplo, para evitar sobreposições ou para emendar exatamente o ad com o conteúdo principal.
[0133] De acordo com as técnicas desta descrição, o dispositivo restrito 288 (por exemplo, o dispositivo cliente 40 da FIG. 1) e o servidor ad 284 (por exemplo, o dispositivo servidor 60 da FIG. 1) podem trocar qualquer uma ou todas as informações a seguir: • O dispositivo restrito 288 pode sinalizar dados representando informações relevantes, incluindo qualquer uma ou todas as propriedades de conteúdo, status de reprodução, recursos de dispositivo, informações de usuário, outras informações típicas de inserção de ad e/ou partição de tempo para inserção de ad. O servidor ad 284 pode utilizar essas informações para personalizar o conteúdo de ad para uma reprodução perfeita e adequada. • O servidor ad 284 (ou gerador de manifesto 286) pode sinalizar parte das informações relevantes (conforme descrito acima) em um arquivo de manifesto (tal como uma MPD DASH) do conteúdo principal. o Por exemplo, o servidor ad 284 pode sinalizar uma partição de tempo de inserção de ad e propriedades de conteúdo estático. • O dispositivo restrito 288 pode sinalizar as informações relevantes acima nos parâmetros de consulta para o servidor ad
284. • O dispositivo restrito 288 pode sinalizar as informações relevantes acima nos cabeçalhos HTTP para o servidor ad 284. • As informações relevantes discutidas acima podem incluir qualquer um ou todas dentre: o Propriedades de conteúdo, status de reprodução, recursos de dispositivo, informações de usuário, outras informações típicas de inserção de ad e/ou parição de tempo de inserção de ad. • As propriedades do conteúdo podem incluir, mas não estão limitadas a: o Para cada tipo de mídia de vídeo Codec, perfil e nível Taxa de quadros Esquema de criptografia Resolução espacial Características de transferência Esquema de cores Etc. o Para cada tipo de mídia de áudio Codec, perfil e nível Frequência de amostragem Configuração de canal de saída Etc. • As propriedades de conteúdo podem ser expressas como qualquer um ou todos dentre: o Cabeçalho do filme, cabeçalho CMAF, tipos mime e parâmetros sub-mime, sinalização DASH MPD, etc. • O status da reprodução pode ser expresso como: o Último tempo reproduzida no tempo de decodificação da mídia, tempo de apresentação • Os recursos do dispositivo expressos como o Versão MSE o Recursos de CTA WAVE o Número de buffers de origem o Etc. • O conteúdo de ad expresso como o Período na MPD o Outra MPD o Manifesto de sinalização de alto nível (HLS) o Arquivo ISO BMFF
[0134] O dispositivo restrito 288 pode sinalizar as informações de anúncio para o servidor ad 284 de várias maneiras. Por exemplo, o dispositivo restrito 288 pode adicionar uma sequência de consultas a uma solicitação de submanifesto com as propriedades de uma ou mais propriedades de conteúdo, os recursos de dispositivo e/ou a temporização. Adicionalmente ou alternativamente, o dispositivo restrito 288 pode adicionar um cabeçalho de extensão HTTP dedicado à solicitação para o manifesto ou submanifesto. Adicionalmente ou alternativamente, o dispositivo restrito 288 pode adicionar uma URL na solicitação para o manifesto ou submanifesto correspondente a uma localização de rede a partir da qual o servidor ad 284 pode obter informações de anúncio para o dispositivo restrito 288.
[0135] A FIG. 8 é um diagrama de fluxos ilustrando um método de exemplo pelo qual as técnicas desta descrição podem ser realizadas. O método da FIG. 8 inclui ações realizadas pelo, por exemplo, servidor de conteúdo principal 282, pelo servidor ad 284, pelo gerador de manifesto 286 e pelo dispositivo restrito 288 da FIG. 7, neste exemplo. Deve ser entendido que em outros exemplos, outros dispositivos (tais como o dispositivo servidor 60, o dispositivo de preparação de conteúdo 20 e o dispositivo cliente 40 (FIG. 1), juntamente com um dispositivo servidor ad separado (não mostrado na FIG. 1) podem ser configurados para realizar este método ou um método similar de acordo com as técnicas desta descrição.
[0136] Inicialmente, o servidor de conteúdo principal 282 envia o conteúdo de manifesto para o gerador de manifesto 286 (300). Por exemplo, o servidor de conteúdo principal 282 pode enviar dados representando conjuntos de dados de áudio e de vídeo para o conteúdo principal, por exemplo, formatos, codecs, linguagens, taxas de bits e similares. O gerador de manifesto 286 pode então gerar um arquivo de manifesto (tal como uma descrição de apresentação de mídia (MPD)) e fornecer o arquivo de manifesto (302) para o dispositivo restrito 288.
[0137] O dispositivo restrito 288 pode então analisar o arquivo de manifesto e selecionar o conteúdo apropriado, então solicitar os principais segmentos de conteúdo (304) do conteúdo selecionado. Por exemplo, o dispositivo restrito 288 pode selecionar o conteúdo com base nos recursos de dispositivo (por exemplo, recursos de decodificação e renderização), largura de banda de rede disponível e preferências de usuário (por exemplo, preferências de linguagem). Parâmetros adicionais podem incluir, por exemplo, codecs suportados por decodificadores do dispositivo restrito 288, resolução espacial e temporal de uma tela, recursos de alta faixa dinâmica (HDR), recursos de codec de áudio e renderização e similares. Para solicitar os segmentos, o dispositivo restrito 288 pode enviar solicitações Get HTTP ou Get parcial para URLs fornecidos no arquivo de manifesto para segmentos correspondentes ao conteúdo selecionado.
[0138] Em algum ponto no tempo, o servidor de conteúdo principal 282 fornece uma oportunidade de inserção de ad (306) para o gerador de manifesto 286. O servidor ad 284 pode também fornecer um link para o conteúdo de ad (308) para o gerador de manifesto 286. O servidor de conteúdo principal 282 pode também adicionar um sinal ao conteúdo para expirar o arquivo de manifesto (310) que o dispositivo restrito 288 recebeu anteriormente, para solicitar que um cliente de streaming do dispositivo restrito 288 solicite um arquivo de manifesto atualizado, incluindo a oportunidade ad (312). Em resposta à solicitação, o gerador de manifesto 286 pode enviar um manifesto atualizado pelo conteúdo de ad (314) para o dispositivo restrito 288. O manifesto atualizado pode incluir um submanifesto que tem como alvo o reprodutor de mídia do dispositivo restrito 288 para o servidor ad 284. O dispositivo restrito 288 pode gerar a solicitação para o arquivo de manifesto atualizado para incluir parâmetros adicionais, de modo que o servidor ad 284 esteja ciente do conteúdo atualmente em reprodução, informações de personalização e similares, bem como dos recursos do reprodutor de mídia do dispositivo restrito 288.
[0139] O dispositivo restrito 288 pode utilizar várias técnicas para indicar parâmetros do conteúdo principal atualmente em execução para o gerador de manifesto 286 e/ou para o servidor ad 284. Por exemplo, o dispositivo restrito 288 pode enviar um cabeçalho/segmento de inicialização/cabeçalho CMAF atual de cada trilha atualmente sendo reproduzida para o gerador de manifesto 286 e/ou para o servidor ad 284. Esses dados de cabeçalho geralmente fornecem uma boa visão geral de codecs, formatos e similares. Em outro exemplo, o dispositivo restrito 288 pode enviar dados tipo mime tais com codecs, subparâmetros ou similares. Em alguns exemplos, o dispositivo restrito 288 pode enviar adicionalmente o tempo de apresentação da última amostra apresentada, a fim de fornecer uma apresentação contínua.
[0140] Utilizando o manifesto atualizado, o dispositivo restrito 288 pode solicitar os segmentos de conteúdo de ad tendo parâmetros do conteúdo principal previamente recuperado (316) a partir do servidor ad 284, por exemplo, o mesmo codec, a mesma taxa de quadros, a mesma resolução espacial, a mesma linguagem e similares. Ou seja, o dispositivo restrito 288 pode enviar informações ad para o servidor ad 284. Novamente, essas solicitações para segmentos de conteúdo de ad podem ser solicitações HTTP Get ou Get parcial. Essas solicitações podem especificar as informações de anúncio. Em resposta a essas solicitações, o servidor ad 284 pode fornecer conteúdo de ad (318) para o dispositivo restrito 288. O dispositivo restrito 288 pode também solicitar outro arquivo de manifesto atualizado com parâmetros do conteúdo de ad (320) a partir do gerador de manifesto 286, que pode fornecer o arquivo de manifesto atualizado pelo conteúdo principal (322) para o dispositivo restrito 288. O dispositivo restrito 288 pode então retomar a solicitação dos segmentos de conteúdo principais, conforme discutido acima com relação à etapa 304. O dispositivo restrito 288 pode também reproduzir os dados de mídia recebidos, ou seja, o conteúdo de mídia principal e o conteúdo de ad. Dessa maneira, o dispositivo restrito 288 pode provisionar o conteúdo de ad para o conteúdo de mídia principal (por exemplo, decodificar o conteúdo de ad junto com o conteúdo de mídia principal).
[0141] Um problema geralmente observado é o problema do conteúdo de emenda para o qual dois tipos de mídia, geralmente áudio e vídeo, têm "tempos finais" diferentes antes do ponto de emenda ou tempos de início diferentes. Neste caso, a transição para cada tipo de mídia deve ser feita com cuidado e individualmente. Isto pode incluir que, por exemplo, um dos tipos de mídia tenha uma lacuna ou o conteúdo possa se sobrepor. A sobreposição pode ser difícil em um único buffer de origem, pois o ponto de emenda é ambíguo. Lacunas podem causar problemas porque a reprodução fica paralisada ou interrompida.
[0142] Desta maneira, o método da FIG. 8 representa um exemplo de um método para receber de dados de mídia, incluindo enviar, por meio de um ou mais processadores implementados no conjunto de circuitos de um dispositivo cliente, informações de anúncio para um dispositivo servidor de anúncio, em resposta ao envio das informações de anúncio, receber, por meio de um ou mais processadores, conteúdo de anúncio a partir do servidor de anúncio, receber, por meio de um ou mais processadores, dados de mídia principais e provisionar, por meio de um ou mais processadores, o conteúdo da anúncio para os dados de mídia principais.
[0143] A FIG. 9 é um fluxograma ilustrando um método de exemplo para recuperar dados de mídia de acordo com as técnicas desta descrição. O método da FIG. 9 é explicado em relação ao dispositivo cliente 40 da FIG. 1 para fins de exemplo. No entanto, deve ser entendido que outros dispositivos podem ser configurados para realizar este método ou um método similar, tal como o dispositivo restrito 288 da FIG. 7)
[0144] Inicialmente, a unidade de recuperação 52 do dispositivo cliente 40 recupera um arquivo de manifesto para o conteúdo principal (350). Por exemplo, um usuário pode solicitar a exibição de um filme específico, e a unidade de recuperação 52 pode determinar um arquivo de manifesto associado com o conteúdo principal correspondente ao filme selecionado pelo usuário. A unidade de recuperação 52 pode então recuperar o arquivo de manifesto, por exemplo, emitindo uma solicitação Get HTTP direcionada para um URL associado com o arquivo de manifesto. Como discutido acima, o arquivo de manifesto pode ser uma MPD DASH.
[0145] A unidade de recuperação 52 pode então determinar o conteúdo principal para ser recuperado (352). Por exemplo, a unidade de recuperação 52 pode determinar os recursos de codificação e renderização do decodificador de vídeo 48, do decodificador de áudio 46, da saída de vídeo 44 e da saída de áudio 42, bem como as preferências de usuário (tal como preferências de linguagem) e, em seguida, selecionar os conjuntos de adaptação adequados de acordo com estes recursos e preferências. A unidade de recuperação 52 pode então selecionar representações dentro dos conjuntos de adaptação de acordo com a largura de banda de rede disponível. A unidade de recuperação 52 pode, então, solicitar segmentos do conteúdo principal (354), por exemplo, emitindo solicitações Get HTTP ou Get parcial para recuperar segmentos das representações selecionadas.
[0146] Em algum ponto, o dispositivo de preparação de conteúdo 20 ou o dispositivo servidor 60 pode enviar dados indicando que o arquivo de manifesto expirou. O dispositivo de preparação de conteúdo 20 pode emitir esses dados em resposta à determinação de que um anúncio está para ser inserido no conteúdo principal. Da mesma forma, o dispositivo cliente 40 pode receber os dados indicando que o arquivo de manifesto expirou (356). Esses dados podem ser incluídos em banda com o conteúdo principal recuperado ou como informação lateral. Em resposta, a unidade de recuperação 52 pode recuperar um arquivo de manifesto atualizado sinalizando a disponibilidade de conteúdo de ad (358).
[0147] Em resposta, a unidade de recuperação 52 pode enviar informações de anúncio para um dispositivo servidor ad (360). As informações do anúncio podem ser representativas do conteúdo principal selecionado (por exemplo, codec, taxa de quadros, resolução etc.), de informações indicando um perfil para um usuário do dispositivo cliente 40 para garantir que o conteúdo de ad seja relevante e interessante para o usuário, ou de seu gosto. Em resposta, a unidade de recuperação 52 pode receber conteúdo de ad a partir do servidor de anúncios (362). Após receber o conteúdo de ad, a unidade de recuperação 52 pode recuperar mais uma vez um arquivo de manifesto atualizado para o conteúdo principal (364) e recuperar o conteúdo principal (366) utilizando o arquivo de manifesto atualizado. O dispositivo cliente 60 pode então provisionar o conteúdo de ad para o conteúdo principal (368). Ou seja, a unidade de recuperação 52 pode fornecer o conteúdo principal e o conteúdo de ad conjuntamente para serem decodificados, processados e apresentados por meio do dispositivo cliente 60.
[0148] Desta maneira, o método da FIG. 9 representa um exemplo de um método para receber dados de mídia, incluindo enviar, por meio de um ou mais processadores implementados em conjunto de circuitos de um dispositivo cliente, informações de anúncio para um dispositivo servidor de anúncio, em resposta ao envio de informações de anúncio, receber, por meio de um ou mais processadores, conteúdo de anúncio a partir do servidor de anúncio, receber, por meio de um ou mais processadores, dados de mídia principais e provisionar, por meio de um ou mais processadores, o conteúdo da anúncio para os dados de mídia principais.
[0149] Em um ou mais exemplos, as funções descritas podem ser implementadas em hardware, software, firmware ou qualquer combinação deles. Se implementadas em software, as funções podem ser armazenadas ou transmitidas como uma ou mais instruções ou códigos em um meio legível por computador e executadas por uma unidade de processamento baseada em hardware. Meio legível por computador pode incluir meio de armazenamento legível por computador, que corresponde a um meio tangível, tal como meio de armazenamento de dados ou meio 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. Desta maneira, o meio legível por computador geralmente pode corresponder a (1) meio de armazenamento legível por computador tangível que é não transitório ou (2) um meio de comunicação tal como um sinal ou uma onda portadora. O meio de armazenamento de dados pode ser qualquer meio disponível que possa ser acessado por um ou mais computadores ou um ou mais processadores para recuperar instruções, código e/ou estruturas de dados para implementação das técnicas apresentadas nesta descrição. Um produto de programa de computador pode incluir um meio legível por computador.
[0150] A título de exemplo e não de limitação, tal meio de armazenamento legível por computador pode compreender RAM, ROM, EEPROM, CD-ROM ou outro armazenamento em disco ótico, armazenamento em disco magnético, ou outros dispositivos de armazenamento magnéticos, memória flash, ou qualquer outro meio que possa ser utilizado para armazenar o código do programa desejado na forma de instruções ou estruturas de dados e que possa ser acessado por um computador. Também, qualquer conexão é corretamente denominada como um meio legível por computado. Por exemplo, se as instruções forem transmitidas a partir de um site, de um servidor ou de outra fonte remota utilizando um cabo coaxial, cabo de fibra óptica, par trançado, linha de assinante digital (DSL) ou tecnologias sem fio tais como infravermelho, rádio e micro-ondas, então o cabo coaxial, o cabo de fibra óptica, o par trançado, a DSL ou as tecnologias sem fio tais como infravermelho, rádio e micro-ondas estão incluídos na definição de meio. Deve ser entendido, no entanto, que meio de armazenamento legível por computador e meio de armazenamento de dados não compreendem conexões, ondas portadoras, sinais ou outros meios de comunicação transitórios, mas em vez disso são direcionados para os meios de armazenamento tangíveis não transitórios. Disco (disk) e disco (disc), conforme utilizado neste documento, inclui disco compacto (CD), disco laser, disco ótico, disco versátil digital (DVD), disquetes e discos Blu-ray, onde discos (disks) normalmente reproduzem dados magneticamente, enquanto discos (discs) reproduzem dados oticamente com lasers. As combinações desses últimos também devem ser incluídas no âmbito do meio legível por computador.
[0151] As instruções podem ser executadas por meio de um ou mais processadores, tais como um ou mais processadores de sinal digital (DSPs), microprocessadores de propósito geral, circuitos integrados de aplicação específica (ASICs), arranjos de portas programáveis em campo (FPGAs) ou outros conjuntos de circuitos equivalente de lógica integrada ou discreta. Nesse sentido, o termo "processador", conforme utilizado neste documento pode se referir a qualquer um dentre as estruturas acima ou qualquer outra estrutura adequada para a aplicação das técnicas descritas neste documento. Adicionalmente, em alguns aspectos, a funcionalidade descrita neste documento pode ser fornecida dentro de módulos de hardware e/ou software dedicados configurados para codificação e decodificação, ou incorporados em um codec combinado. Além disso, as técnicas podem ser totalmente implementadas em um ou mais circuitos ou elementos de lógica.
[0152] As técnicas desta descrição podem ser implementadas em uma ampla variedade de dispositivos ou aparelhos, incluindo um aparelho de telefone sem fio, um circuito integrado (IC) ou um conjunto de ICs (por exemplo, um conjunto de chips). Vários componentes, módulos ou unidades são apresentados nesta descrição para enfatizar os aspectos funcionais dos dispositivos configurados para realizar as técnicas descritas, mas que não necessariamente exigem a realização por diferentes unidades de hardware. Pelo contrário, conforme descrito acima, diversas unidades podem ser combinadas em uma unidade de hardware de codec ou fornecidas por uma coleção de unidades de hardware interoperativas, incluindo um ou mais processadores, conforme descrito acima, em conjunção com o software e/ou com o firmware adequado.
[0153] Vários exemplos foram descritos. Estes e outros exemplos estão dentro do escopo das reivindicações a seguir.
Claims (30)
1. Método para recuperar dados de mídia, o método compreendendo: enviar, por meio de um ou mais processadores implementados em conjunto de circuitos de um dispositivo cliente, informações de anúncio para um dispositivo servidor de anúncio; receber, em resposta ao envio das informações de anúncio, por meio de um ou mais processadores, conteúdo de anúncio a partir do servidor de anúncio; recuperar, por meio dos um ou mais processadores, os dados de mídia principais; e provisionar, por meio dos um ou mais processadores, o conteúdo de anúncio para os dados de mídia principais.
2. Método, de acordo com a reivindicação 1, em que provisionar compreende provisionar o anúncio para os dados de mídia principais para serem exibidos dentro de um buffer de origem do dispositivo cliente.
3. Método, de acordo com a reivindicação 1, em que enviar as informações de anúncio compreende enviar os dados que representam uma ou mais dentre as qualidades de dados de mídia que podem ser decodificados ou renderizados por meio do dispositivo cliente, um ou mais recursos para dados de mídia que são suportados pelo dispositivo cliente, qualidades de correspondência dos dados de mídia principais, solicitações de conteúdo de anúncio em um ponto de emenda de anúncio, informações de personalização para um usuário do dispositivo cliente ou duração de uma partição de anúncio.
4. Método, de acordo com a reivindicação 3, em que as qualidades de correspondência compreendem uma ou mais dentre as prevenções de redefinições de HDMI, reinicialização de buffer de origem, quadros em preto desnecessários, criptografia e informações de incompatibilidade de conteúdo protegido, configurações de codec de áudio ou recursos do dispositivo cliente.
5. Método, de acordo com a reivindicação 1, em que enviar as informações de anúncio compreende enviar dados que representam um ou mais dentre os recursos do dispositivo cliente, uma partição de tempo de inserção de anúncio, propriedades dos dados de mídia principais ou uma última temporização reproduzida dos dados de mídia principais para um componente de mídia.
6. Método, de acordo com a reivindicação 5, em que os dados que representam os um ou mais recursos do dispositivo cliente compreendem dados que representam como o dispositivo cliente pode lidar com a inserção de anúncio.
7. Método, de acordo com a reivindicação 5, em que os dados que representam os um ou mais recursos do dispositivo cliente compreendem dados que representam se o dispositivo cliente suporta um ou mais de um único buffer de origem com inicialização estática, propriedades HDMI, múltiplos buffers de origem ou operação de extensões de fonte de mídia (MSE) comum.
8. Método, de acordo com a reivindicação 5, em que os dados que representam a partição de tempo de inserção de anúncio compreendem dados representativos de um anúncio apropriado e limites de anúncio para a partição de tempo de inserção de anúncio.
9. Método, de acordo com a reivindicação 5, em que os dados que representam as propriedades dos dados de mídia principais compreendem um Cabeçalho do Formato de Aplicativo de Mídia Comum (CMAF) do conteúdo de mídia principal de um ou mais componentes de mídia.
10. Método, de acordo com a reivindicação 5, em que os dados que representam a última temporização reproduzida compreendem dados que representam como o conteúdo de anúncio pode ser emendado com os dados de mídia principais.
11. Método, de acordo com a reivindicação 1, em que enviar as informações de anúncio compreende enviar uma ou mais dentre propriedades de conteúdo para os dados de mídia principais, status de reprodução para os dados de mídia principais, recursos do dispositivo cliente, informações de usuário para um usuário do dispositivo cliente ou informações de partição de tempo de inserção de anúncio.
12. Método, de acordo com a reivindicação 11, compreendendo adicionalmente: receber um arquivo de manifesto para o conteúdo de mídia principal; e determinar as informações de anúncio para serem enviadas para o dispositivo servidor de anúncio a partir dos dados do arquivo de manifesto.
13. Método, de acordo com a reivindicação 12, em que determinar as informações de anúncio a partir dos dados do arquivo de manifesto compreende determinar um ou mais entre uma partição de tempo de inserção de anúncio ou propriedades de conteúdo estático a partir dos dados do arquivo de manifesto.
14. Método, de acordo com a reivindicação 11, em que as propriedades do conteúdo incluem, para mídia de vídeo do conteúdo de mídia principal, um ou mais dentre um codec de vídeo, uma indicação de perfil, uma indicação de nível, uma taxa de quadros, um esquema de criptografia, características de transferência ou esquema de cor.
15. Método, de acordo com a reivindicação 11, em que as propriedades de conteúdo incluem, para mídia de áudio do conteúdo de mídia principal, um ou mais dentre um codec de áudio, uma indicação de perfil, uma indicação de nível, uma frequência de amostragem ou uma configuração de canal de saída.
16. Método, de acordo com a reivindicação 11, em enviar as informações de anúncio compreende enviar as propriedades de conteúdo expressas como um ou mais dentre um cabeçalho de filme, um cabeçalho CMAF, tipos MIME, tipos sub-MIME ou sinalização MPD DASH.
17. Método, de acordo com a reivindicação 11, em enviar as informações de anúncio compreende enviar os recursos do dispositivo cliente, expresso como uma ou mais dentre uma versão de extensões de fonte de mídia (MSE), um ou mais recursos de Ecossistema de Vídeo de Aplicação Web da Associação de Tecnologia de Consumidor (CTA WAVE) ou um número de buffers de origem suportados pelo dispositivo cliente.
18. Método, de acordo com a reivindicação 1, em que enviar as informações de anúncio compreende enviar pelo menos uma parte das informações de anúncio em um ou mais parâmetros de consulta.
19. Método, de acordo com a reivindicação 1, em enviar as informações de anúncio compreende enviar pelo menos uma parte das informações de anúncio em um ou mais cabeçalhos HTTP.
20. Método, de acordo com a reivindicação 1, compreendendo adicionalmente receber dados descritivos para o conteúdo de anúncio, os dados descritivos expressos como um ou mais dentre um período em um arquivo de manifesto para o conteúdo da mídia principal, um arquivo de manifesto específico para o conteúdo de anúncio e separado do arquivo de manifesto para o conteúdo da mídia principal, um manifesto de sinalização de alto nível (HLS) ou nos dados de um arquivo de Formato de Arquivo de Mídia com Base ISO (BMFF).
21. Dispositivo para recuperar dados de mídia, o dispositivo compreendendo: uma memória configurada para armazenar dados de mídia, incluindo conteúdo de anúncio e dados de mídia principais; e um ou mais processadores implementados em conjunto de circuitos e configurados para: enviar informações de anúncio para um dispositivo servidor de anúncio; receber, em resposta ao envio das informações de anúncio, o conteúdo de anúncio a partir do servidor de anúncio; recuperar os dados de mídia principais; e provisionar o conteúdo de anúncio para os dados de mídia principais.
22. Dispositivo, de acordo com a reivindicação
21, compreendendo adicionalmente um decodificador de vídeo e um buffer de imagem codificada a partir do qual o decodificador de vídeo recupera dados de vídeo codificados a serem decodificados, em que para provisionar o conteúdo de anúncio aos dados de mídia principais, os um ou mais processadores são configurados para armazenar o conteúdo de anúncio e os dados de mídia principais para o buffer de imagem codificada.
23. Dispositivo, de acordo com a reivindicação 21, em que as informações de anúncio compreendem um ou mais dados de qualidade de mídia que podem ser decodificados ou renderizados por meio do dispositivo, um ou mais recursos para dados de mídia que são suportados pelo dispositivo, qualidades de correspondência dos dados de mídia principais, requisitos do conteúdo de anúncio em um ponto de emenda de anúncio, informações de personalização para um usuário do dispositivo ou duração de uma partição de anúncio.
24. Dispositivo, de acordo com a reivindicação 21, em que as informações de anúncio compreendem um ou mais recursos do dispositivo cliente, uma partição de tempo de inserção de anúncio, propriedades dos dados de mídia principais ou uma última temporização reproduzida dos dados de mídia principais para um componente de mídia.
25. Dispositivo, de acordo com a reivindicação 21, em que as informações de anúncio compreendem uma ou mais propriedades de conteúdo para os dados de mídia principais, status de reprodução para os dados de mídia principais, recursos de decodificação ou renderização do dispositivo, informações de usuário para um usuário do dispositivo cliente ou informações de partição de tempo de inserção de anúncio.
26. Dispositivo, de acordo com a reivindicação 21, em que os um ou mais processadores são configurados para enviar pelo menos uma parte das informações de anúncio em um ou mais parâmetros de consulta.
27. Dispositivo, de acordo com a reivindicação 21, em que os um ou mais processadores são configurados para enviar pelo menos uma parte das informações de anúncio em um ou mais cabeçalhos HTTP.
28. Dispositivo, de acordo com a reivindicação 21, em que os um ou mais processadores são configurados para receber dados descritivos para o conteúdo de anúncio, os dados descritivos expressos como um ou mais dentre um período em um arquivo de manifesto para o conteúdo de mídia principal, um arquivo de manifesto específico para o conteúdo do anúncio e separado do arquivo de manifesto para o conteúdo de mídia principal, um manifesto de sinalização de alto nível (HLS) ou em dados de um arquivo de Formato de Arquivo de Mídia com Base ISO (BMFF).
29. Meio de armazenamento legível por computador tendo instruções armazenadas no mesmo que, quando executadas, fazem com que um processador de um dispositivo cliente: envie informações de anúncio para um dispositivo servidor de anúncio; receba, em resposta ao envio das informações de anúncio, o conteúdo de anúncio a partir do servidor de anúncio; recupere dados principais da mídia; e provisione o conteúdo de anúncio para os dados de mídia principais.
30. Dispositivo para receber dados de mídia, o dispositivo compreendendo: meios para enviar informações de anúncio para um dispositivo servidor de anúncio; meios para receber, em resposta ao envio de informações de anúncio, conteúdo de anúncio a partir do servidor de anúncio; meios para receber dados da mídia principais; e meios para provisionar o conteúdo de anúncio para os dados da mídia principais.
Applications Claiming Priority (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201862624603P | 2018-01-31 | 2018-01-31 | |
| US62/624,603 | 2018-01-31 | ||
| US201862633472P | 2018-02-21 | 2018-02-21 | |
| US62/633,472 | 2018-02-21 | ||
| US16/262,273 US12075133B2 (en) | 2018-01-31 | 2019-01-30 | Dynamic conditional advertisement insertion |
| US16/262,273 | 2019-01-30 | ||
| PCT/US2019/016019 WO2019152631A1 (en) | 2018-01-31 | 2019-01-31 | Dynamic conditional advertisement insertion |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BR112020015214A2 true BR112020015214A2 (pt) | 2021-01-26 |
Family
ID=67391655
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BR112020015214-5A BR112020015214A2 (pt) | 2018-01-31 | 2019-01-31 | inserção dinâmica de anúncio condicional |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US12075133B2 (pt) |
| EP (2) | EP4329323A3 (pt) |
| CN (2) | CN111656796B (pt) |
| BR (1) | BR112020015214A2 (pt) |
| SG (1) | SG11202005818VA (pt) |
| WO (1) | WO2019152631A1 (pt) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018066355A1 (ja) * | 2016-10-04 | 2018-04-12 | ソニー株式会社 | 受信装置、送信装置、及び、データ処理方法 |
| CN112714360B (zh) * | 2019-10-25 | 2023-05-16 | 上海哔哩哔哩科技有限公司 | 媒体内容播放方法和系统 |
| US11290575B2 (en) * | 2020-02-06 | 2022-03-29 | International Business Machines Corporation | Connecting computer processing systems and transmitting data |
| US11357020B2 (en) | 2020-02-06 | 2022-06-07 | International Business Machines Corporation | Connecting computer processing systems and transmitting data |
| US11405766B2 (en) | 2020-02-06 | 2022-08-02 | International Business Machines Corporation | Connecting computer processing systems and transmitting data |
| CN111225244B (zh) * | 2020-02-19 | 2022-03-01 | 聚好看科技股份有限公司 | 广告展示方法、服务器、显示设备 |
| US11647252B2 (en) * | 2020-02-28 | 2023-05-09 | Hulu, LLC | Identification of elements in a group for dynamic element replacement |
| EP4111698A4 (en) | 2020-02-28 | 2024-03-13 | Hulu, LLC | CLIENT-BASED REMOTE ELEMENT RESOLUTION STORAGE |
| US11290514B2 (en) * | 2020-05-18 | 2022-03-29 | Tencent America LLC | Method for content preparation templates for 5G common media application format based media streaming |
| CN116635397A (zh) * | 2020-11-19 | 2023-08-22 | F.I.S.-菲博利佳意大利合成面料股份公司 | 改进的制备群勃龙和/或醋酸群勃龙的方法 |
| US11818189B2 (en) * | 2021-01-06 | 2023-11-14 | Tencent America LLC | Method and apparatus for media streaming |
| GB2617048B (en) * | 2021-01-06 | 2024-10-23 | Canon Kk | Method and apparatus for encapsulating uncompressed images and uncompressed video data into a file |
| US11750678B2 (en) * | 2021-05-12 | 2023-09-05 | Tencent America LLC | Manifest based CMAF content preparation template for 5G networks |
| FR3124344A1 (fr) * | 2021-06-23 | 2022-12-23 | Orange | Procédé de gestion d’accès à des contenus téléchargés en mode de téléchargement adaptatif. |
| US11973820B2 (en) * | 2021-10-06 | 2024-04-30 | Tencent America LLC | Method and apparatus for mpeg dash to support preroll and midroll content during media playback |
| US11799943B2 (en) | 2021-10-06 | 2023-10-24 | Tencent America LLC | Method and apparatus for supporting preroll and midroll during media streaming and playback |
Family Cites Families (43)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11132720B2 (en) * | 2001-05-11 | 2021-09-28 | Iheartmedia Management Services, Inc. | Media delivery to limited capability platforms |
| US7908295B2 (en) * | 2004-04-23 | 2011-03-15 | Tvworks, Llc | Extending data records for dynamic data and selective acceptance based on hardware profile |
| CN101212304A (zh) | 2006-12-29 | 2008-07-02 | 上海亿动信息技术有限公司 | 一种对网络广告的多个备选版本选择发布的方法和装置 |
| WO2008131176A2 (en) * | 2007-04-18 | 2008-10-30 | Behr John | Systems and methods for providing wireless advertising to mobile device users |
| US8510773B1 (en) * | 2007-06-27 | 2013-08-13 | Verve Wireless, Inc. | Systems and methods for providing targeted advertising and content delivery to mobile devices |
| US8893203B2 (en) * | 2007-08-17 | 2014-11-18 | Phoenix Myrrh Technology Pty Ltd. | Method and system for content delivery |
| US10264029B2 (en) * | 2009-10-30 | 2019-04-16 | Time Warner Cable Enterprises Llc | Methods and apparatus for packetized content delivery over a content delivery network |
| US20110179446A1 (en) * | 2010-01-15 | 2011-07-21 | Jeyhan Karaoguz | System and method for communicating programming and advertising content through diverse communication networks |
| CN104394487B (zh) * | 2010-03-05 | 2018-02-06 | 三星电子株式会社 | 基于文件格式生成和再现自适应流的方法和装置 |
| CN102804686B (zh) | 2010-03-16 | 2016-08-24 | 三星电子株式会社 | 内容输出系统及其编解码器信息共享方法 |
| WO2011139305A1 (en) * | 2010-05-04 | 2011-11-10 | Azuki Systems, Inc. | Method and apparatus for carrier controlled dynamic rate adaptation and client playout rate reduction |
| US9762639B2 (en) * | 2010-06-30 | 2017-09-12 | Brightcove Inc. | Dynamic manifest generation based on client identity |
| US8677428B2 (en) * | 2010-08-20 | 2014-03-18 | Disney Enterprises, Inc. | System and method for rule based dynamic server side streaming manifest files |
| US20120144420A1 (en) | 2010-12-07 | 2012-06-07 | General Instrument Corporation | Targeted advertisement distribution in an sdv environment |
| US8990351B2 (en) * | 2011-04-20 | 2015-03-24 | Mobitv, Inc. | Real-time processing capability based quality adaptation |
| US20140040026A1 (en) | 2012-05-04 | 2014-02-06 | Adobe Systems Incorporated | Systems and methods for including advertisements in streaming content |
| BR122015005194A2 (pt) | 2012-06-28 | 2019-08-20 | Ericsson Ab | Método e sistema para inserção de anúncio em entrega de mídia ao vivo over the top |
| EP2722808A1 (en) | 2012-09-17 | 2014-04-23 | OpenTV, Inc. | Automatic localization of advertisements |
| US8732745B2 (en) | 2012-10-22 | 2014-05-20 | Sony Corporation | Method and system for inserting an advertisement in a media stream |
| US9369766B2 (en) | 2012-11-06 | 2016-06-14 | Yahoo! Inc. | Method and system for remote altering static video content in real time |
| US9100721B2 (en) * | 2012-12-06 | 2015-08-04 | Cable Television Laboratories, Inc. | Advertisement insertion |
| US9357248B2 (en) * | 2013-03-13 | 2016-05-31 | Arris Enterprises, Inc. | Method and apparatus for adaptive bit rate content delivery |
| US9444863B2 (en) | 2013-06-06 | 2016-09-13 | Intel Corporation | Manager for DASH media streaming |
| US9160540B2 (en) * | 2013-07-25 | 2015-10-13 | Adobe Systems Incorporated | Preventing playback of streaming video if ads are removed |
| US9258747B2 (en) | 2013-09-17 | 2016-02-09 | Intel IP Corporation | User equipment and methods for fast handover failure recovery in 3GPP LTE network |
| CN103561279B (zh) | 2013-10-10 | 2017-02-01 | 中兴通讯股份有限公司 | 一种多媒体文件播放的方法、系统及云转码服务设备 |
| US9635398B2 (en) * | 2013-11-01 | 2017-04-25 | Adobe Systems Incorporated | Real-time tracking collection for video experiences |
| US10902474B2 (en) | 2014-03-24 | 2021-01-26 | Qualcomm Incorporated | Targeted advertisement insertion for streaming media data |
| US9621938B2 (en) * | 2014-09-10 | 2017-04-11 | Ericsson Ab | Advertisement targeting scheme in a multicast ABR environment based on switched video |
| US9591379B2 (en) * | 2014-10-30 | 2017-03-07 | Net2.TV, LTD. | Systems and methods for providing an advertisement calling proxy server |
| US9838760B2 (en) * | 2014-12-16 | 2017-12-05 | Arizona Board Of Regents On Behalf Of Arizona State University | Systems and methods for name-based segmented media acquisition and distribution framework on a network |
| WO2016100916A1 (en) * | 2014-12-18 | 2016-06-23 | Verance Corporation | Service signaling recovery for multimedia content using embedded watermarks |
| US9479801B2 (en) * | 2014-12-19 | 2016-10-25 | Telefonaktiebolaget L M Ericsson (Publ) | End user-based personalized ad insertion in broadcast-broadband hybrid terminals |
| US20160316233A1 (en) * | 2015-04-21 | 2016-10-27 | Adsparx USA Inc | System and method for inserting, delivering and tracking advertisements in a media program |
| WO2016187592A1 (en) * | 2015-05-21 | 2016-11-24 | Viviso Inc. | Apparatus and method for replacing conventional commercials with targeted advertisements in online live streams |
| US10037592B2 (en) | 2015-06-05 | 2018-07-31 | Mindaptiv LLC | Digital quaternion logarithm signal processing system and method for images and other data types |
| CN105376594A (zh) | 2015-10-28 | 2016-03-02 | 无锡峰巢美家网络科技有限公司 | 一种多平台多终端广告数据同步分发装置与分发系统 |
| US10595054B2 (en) * | 2016-05-10 | 2020-03-17 | Google Llc | Method and apparatus for a virtual online video channel |
| US10313721B1 (en) * | 2016-06-22 | 2019-06-04 | Amazon Technologies, Inc. | Live streaming media content using on-demand manifests |
| WO2018028985A1 (en) * | 2016-08-11 | 2018-02-15 | Telefonaktiebolaget Lm Ericsson (Publ) | Improved adaptive bit rate streaming of live content with manifest update push notification or long poll |
| CN106339908A (zh) | 2016-08-26 | 2017-01-18 | 北京小米移动软件有限公司 | 跟踪广告效果的方法和装置 |
| US20180343479A1 (en) * | 2017-05-26 | 2018-11-29 | Opentv, Inc. | Universal optimized content change |
| US10681104B1 (en) * | 2017-09-13 | 2020-06-09 | Amazon Technologies, Inc. | Handling media timeline offsets |
-
2019
- 2019-01-30 US US16/262,273 patent/US12075133B2/en active Active
- 2019-01-31 SG SG11202005818VA patent/SG11202005818VA/en unknown
- 2019-01-31 EP EP23207795.8A patent/EP4329323A3/en active Pending
- 2019-01-31 BR BR112020015214-5A patent/BR112020015214A2/pt unknown
- 2019-01-31 EP EP19705077.6A patent/EP3747199A1/en not_active Ceased
- 2019-01-31 CN CN201980010780.9A patent/CN111656796B/zh active Active
- 2019-01-31 WO PCT/US2019/016019 patent/WO2019152631A1/en unknown
- 2019-01-31 CN CN202310119124.0A patent/CN116055781A/zh active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| EP3747199A1 (en) | 2020-12-09 |
| CN111656796B (zh) | 2023-02-17 |
| EP4329323A2 (en) | 2024-02-28 |
| US12075133B2 (en) | 2024-08-27 |
| SG11202005818VA (en) | 2020-08-28 |
| WO2019152631A1 (en) | 2019-08-08 |
| US20190238950A1 (en) | 2019-08-01 |
| CN116055781A (zh) | 2023-05-02 |
| EP4329323A3 (en) | 2024-05-22 |
| CN111656796A (zh) | 2020-09-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US12075133B2 (en) | Dynamic conditional advertisement insertion | |
| US9319448B2 (en) | Trick modes for network streaming of coded multimedia data | |
| BR112016022201B1 (pt) | Método para recuperar dados de mídia por um dispositivo cliente que tem um cliente de serviço de multicast de multimídia e um cliente de streaming adaptativo dinâmico sobre http, dispositivo cliente que tem um cliente de serviço de multicast de multimídia e um cliente de streaming adaptativo dinâmico sobre http, e, memória legível por computador | |
| BR112019014070A2 (pt) | dados de sinalização para suporte de pré-busca para transmissão contínua de dados de mídia | |
| BR112020022899A2 (pt) | sinalizar, em um arquivo de manifesto, seções ausentes de dados de mídia para rede de fluxo contínuo | |
| BR112020000015A2 (pt) | processamento de mídia de dados usando um descritor genérico para caixas de formato de arquivo | |
| US20240357213A1 (en) | Dynamic conditional advertisement insertion | |
| BR112016016434B1 (pt) | Método de transmissão adaptativa dinâmica através de http, dispositivo para receber, a partir de um dispositivo de servidor, dados relacionados a dados de mídia de transmissão contínua dash, método e dispositivo de sinalização | |
| BR112016022245B1 (pt) | Método e dispositivo de recuperar dados de mídia | |
| BR112017017152B1 (pt) | Método e dispositivo de cliente para recuperar dados de mídia, método e dispositivo servidor para sinalização de informação de mídia para a recuperação de segmentos de mídia de um conteúdo de mídia e memória legível por computador |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B350 | Update of information on the portal [chapter 15.35 patent gazette] |