BR112016022201B1 - 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 - Google Patents
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 Download PDFInfo
- Publication number
- BR112016022201B1 BR112016022201B1 BR112016022201-6A BR112016022201A BR112016022201B1 BR 112016022201 B1 BR112016022201 B1 BR 112016022201B1 BR 112016022201 A BR112016022201 A BR 112016022201A BR 112016022201 B1 BR112016022201 B1 BR 112016022201B1
- Authority
- BR
- Brazil
- Prior art keywords
- client
- data
- media
- mbms
- dash
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 114
- 230000003044 adaptive effect Effects 0.000 title claims abstract description 12
- 239000012634 fragment Substances 0.000 claims description 30
- 230000004044 response Effects 0.000 claims description 11
- 235000014510 cooky Nutrition 0.000 claims description 5
- 238000013507 mapping Methods 0.000 claims description 3
- 238000003780 insertion Methods 0.000 abstract description 21
- 230000037431 insertion Effects 0.000 abstract description 21
- 230000000875 corresponding effect Effects 0.000 description 32
- 238000003860 storage Methods 0.000 description 28
- 238000010586 diagram Methods 0.000 description 26
- 230000006978 adaptation Effects 0.000 description 23
- 238000011084 recovery Methods 0.000 description 21
- 238000005538 encapsulation Methods 0.000 description 18
- 238000012545 processing Methods 0.000 description 17
- 238000002360 preparation method Methods 0.000 description 14
- 230000005540 biological transmission Effects 0.000 description 9
- 230000007246 mechanism Effects 0.000 description 8
- 230000002123 temporal effect Effects 0.000 description 8
- 230000009471 action Effects 0.000 description 7
- 230000008569 process Effects 0.000 description 7
- 238000013459 approach Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 5
- 230000003993 interaction Effects 0.000 description 5
- 238000009877 rendering Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 238000001914 filtration Methods 0.000 description 4
- 238000007726 management method Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 238000012546 transfer Methods 0.000 description 4
- 230000006835 compression Effects 0.000 description 3
- 238000007906 compression Methods 0.000 description 3
- 238000013500 data storage Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000012800 visualization Methods 0.000 description 3
- 238000003491 array Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 239000000470 constituent Substances 0.000 description 2
- 238000002716 delivery method Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- GVVPGTZRZFNKDS-JXMROGBWSA-N geranyl diphosphate Chemical compound CC(C)=CCC\C(C)=C\CO[P@](O)(=O)OP(O)(O)=O GVVPGTZRZFNKDS-JXMROGBWSA-N 0.000 description 2
- 238000005304 joining Methods 0.000 description 2
- 230000000737 periodic effect Effects 0.000 description 2
- 230000001052 transient effect Effects 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
- 208000027418 Wounds and injury Diseases 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 210000004027 cell Anatomy 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000002860 competitive effect Effects 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000006378 damage Effects 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 208000014674 injury Diseases 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 210000001057 smooth muscle myoblast Anatomy 0.000 description 1
- 241000894007 species Species 0.000 description 1
- 230000000153 supplemental effect Effects 0.000 description 1
- 230000001360 synchronised effect 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
- H04N21/25866—Management of end-user data
- H04N21/25883—Management of end-user data being end-user demographical data, e.g. age, family status or address
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0241—Advertisements
- G06Q30/0251—Targeted advertisements
- G06Q30/0269—Targeted advertisements based on user profile or attribute
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/75—Media network packet handling
- H04L65/765—Media network packet handling intermediate
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
- H04N21/25866—Management of end-user data
- H04N21/25891—Management of end-user data being end-user preferences
-
- 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/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
- H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/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/4508—Management of client data or end-user data
- H04N21/4524—Management of client data or end-user data involving the geographical location of the client
-
- 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/4508—Management of client data or end-user data
- H04N21/4532—Management of client data or end-user data involving end-user characteristics, e.g. viewer profile, preferences
-
- 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/845—Structuring of content, e.g. decomposing content into time segments
- H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/85—Assembly of content; Generation of multimedia applications
- H04N21/854—Content authoring
- H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Business, Economics & Management (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Accounting & Taxation (AREA)
- Development Economics (AREA)
- Marketing (AREA)
- Computer Graphics (AREA)
- Entrepreneurship & Innovation (AREA)
- Game Theory and Decision Science (AREA)
- Economics (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Information Transfer Between Computers (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
INSERÇÃO DE PROPAGANDA DIRECIONADA PARA DADOS DE MÍDIA DE FLUXO CONTÍNUO. Em um exemplo, um método de recuperar dados de mídia inclui, pelo cliente do serviço de multimídia de broadcast/multicast (MBMS) de um dispositivo do cliente: receber dados de mídia de propaganda de um ou mais grupos de propaganda, receber um valor identificador para um dos grupos de propaganda a partir de um fluxo contínuo adaptativo dinâmico através do cliente HTTP (DASH) do dispositivo do cliente; extrair os dados da mídia de propaganda do grupo de anúncio correspondente ao valor do identificador; e fornecer os dados de mídia da propaganda extraídos para o cliente DASH.
Description
[0001] Este pedido reivindica o benefício do Pedido de Patente Provisório N°. US 61/969.707, depositado em 24 de março de 2014 e Pedido de Patente Provisório N°. US 61/973.063 depositado em 31 de março de 2014, os conteúdos totais dos quais estão aqui incorporados na íntegra, a título de referência.
[0002] Esta revelação refere-se ao transporte de dados de mídia, ex., streaming de dados de mídia usando um serviço de transporte de broadcast.
[0003] Capacidades de vídeo digitais podem ser incorporadas em uma ampla gama de dispositivos, incluindo televisores digitais, sistemas de transmissão digital direta, sistemas de transmissão sem fio, assistentes digitais pessoais (PDAs), laptops ou computadores de mesa, câmeras digitais, dispositivos de gravação digital, reprodutores de mídia digitais, dispositivos de jogos de vídeo, videogames, telefones celulares de rádio ou satélite, dispositivos de vídeo de teleconferência e afins. Dispositivos de vídeo digital implementam técnicas de compressão de vídeo, como aquelas descritas nos padrões definidos pelo 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) e Codificação de Vídeo de Alta Eficiência (HEVC) e extensões de tais padrões para transmitir e receber informações de vídeo digital de forma mais eficiente.
[0004] Técnicas de compressão de vídeo realizam a previsão espacial e/ou previsão temporal para reduzir ou eliminar a redundância inerente nas sequências de vídeo. Para a codificação de vídeo baseada em bloco, um quadro de vídeo ou fatia pode ser dividido em macroblocos. Cada macrobloco pode ser dividido adicionalmente. Os macroblocos em um quadro ou fatia intra-codificada (I) são codificados usando a previsão espacial em relação aos macroblocos vizinhos. Os macroblocos em um quadro ou fatia inter-codificada (P ou B) podem usar a previsão espacial em relação aos macroblocos vizinhos no mesmo quadro ou fatia, ou a previsão temporal, no que diz respeito a outras amostras de referência.
[0005] Depois dos dados de vídeo (e/ou outros dados de mídia, como áudio e/ou dados de texto cronometrados) terem sido codificados, os dados de mídia podem ser empacotados para transmissão ou armazenamento. Os dados de mídia em pacotes podem ser transmitidos através de um protocolo de unicast, como protocolo de transferência de hipertexto (HTTP), ou um protocolo de broadcast ou multicast, como Serviço de Broadcast Multicast de Multimídia Avançado (eMBMS).
[0006] De um modo geral, esta revelação descreve técnicas relacionadas com a inserção de publicidade direcionada em dados de mídia. Em particular, um aplicativo de mídia pode fornecer detalhes do usuário e/ou dados do usuário (por exemplo, uma seleção das preferências do usuário) para um cliente de streaming, como um streaming adaptativo dinâmico sobre o cliente HTTP (DASH). O cliente de streaming pode fornecer dados que corresponde a uma unidade de middleware de broadcast ou multicast. A unidade de middleware pode receber dados para um ou mais grupos de publicidade de um servidor de broadcast ou multicast, e, em seguida, selecionar um dos grupos de anúncio com base nos dados do cliente do streaming. Alternativamente, o cliente de streaming pode fornecer um identificador para um dos grupos de anúncio para a unidade de middleware, por exemplo, quando ativa (isto é, dereferencia) um link que inclui um atributo de substituição correspondente a um identificador de um grupo de anúncio, inserindo o identificador como um valor para o atributo no link.
[0007] Em um exemplo, um método de recuperação de dados de mídia inclui, por um streaming adaptativo dinâmica sobre o cliente HTTP (DASH),determinar um conjunto de identificadores de grupo de anúncio associados aos dados de mídia de anúncio de uma pluralidade de grupos de anúncio, sendo que os dados de mídia de anúncio devem ser reproduzidos durante um intervalo publicitário para o conteúdo de mídia principal, sendo que o conteúdo de mídia principal é associado com um arquivo de manifesto, recuperar uma atualização para o arquivo de manifesto, sendo que a atualização define um período remoto que corresponde aos dados de mídia do anúncio, sendo que a atualização para o arquivo de manifesto especifica um modelo para um localizador d recurso uniforme (URL) da linguagem de conexão (XLink) da linguagem de marcação extensível (XML) incluindo um atributo identificador; selecionar, com base, pelo menos em parte nas características de um usuário para o cliente DASH, um dos grupos de anúncio a partir do conjunto, atribuir, de acordo com o modelo, um valor identificador correspondente ao grupo de anúncio selecionado para o atributo identificador do URL Xlink de acordo com o modelo, dereferenciar o URL Xlink incluindo o valor identificador correspondente ao grupo de anúncio selecionado para recuperar dados de mídia do anúncio do grupo de anúncio selecionado a partir do período remoto; e fornecer os dados de mídia do anúncio para um aplicativo de mídia.
[0008] Em outro exemplo, o método de recuperar dados de mídia inclui, pelo cliente do serviço de multimídia de broadcast/multicast (MBMS) de um dispositivo do cliente, receber dados de mídia de anúncio de um ou mais grupos de anúncio, receber um localizador de recurso uniforme (URL) da linguagem de conexão (XLink) da linguagem de marcação extensível (XML) incluindo um valor identificador para um dosgrupos de anúncio a partir de um streaming adaptativo dinâmico através do cliente HTTP (DASH) do dispositivo do cliente; extrair os dados da mídia de anúncio do grupo de anúnciocorrespondente ao valor do identificador; e fornecer os dados de mídia do anúncio extraídos para o cliente DASH.
[0009] Em outro exemplo, uma mídia de armazenamento legível por computador tem armazenadas nela instruções que, quando executadas, fazem com que um processador de um dispositivo cliente determine um conjunto de identificadores de grupo de anúncio associados aos dados de mídia de anúncio de uma pluralidade de grupos de anúncio, sendo que os dados de mídia de anúncio devem ser reproduzidos durante um intervalo publicitário para o conteúdo de mídia principal, sendo que o conteúdo de mídia principal é associado com um arquivo de manifesto, recupere uma atualização para o arquivo de manifesto, sendo que a atualização define um período remoto que corresponde aos dados de mídia do anúncio, sendo que a atualização para o arquivo de manifesto especifica um modelo para um localizador d recurso uniforme (URL) da linguagem de conexão (XLink) da linguagem de marcação extensível (XML) incluindo um atributo identificador; selecione, com base, pelo menos em parte nas características de um usuário para o cliente DASH, um dos grupos de anúncio a partir do conjunto, atribua, de acordo com o modelo, um valor identificador correspondente ao grupo de anúncio selecionado para o atributo identificador do URL XLink de acordo com o modelo, dereferencie o URL XLink incluindo o valor identificador correspondente ao grupo de anúncio selecionado para recuperar dados de mídia do anúncio do grupo de anúncio selecionado a partir do período remoto e forneça os dados de mídia do anúncio para um aplicativo de mídia.
[0010] Em outro exemplo, a mídia de armazenamento legível por computador que tem armazenadas nela instruções que, quando executadas, fazem com que um processador de um dispositivo cliente receba dados de mídia de anúncio de um ou mais grupos de anúncio, receba um localizador de recurso uniforme (URL) da linguagem de conexão (XLink) da linguagem de marcação extensível (XML) incluindo um valor identificador para um dos grupos de anúncio a partir de um streaming adaptativo dinâmico através do cliente HTTP (DASH) do dispositivo do cliente; extraia os dados da mídia de anúncio do grupo de anúncio correspondente ao valor do identificador; e forneça os dados de mídia do anúncio extraídos para o cliente DASH.
[0011] Em outro exemplo, um método de recuperar dados de mídia inclui, por um cliente do serviço de multimídia de broadcast/multicast (MBMS) de um dispositivo do cliente, receber um localizador de recurso uniforme (URL) da linguagem de conexão (XLink) da linguagem de marcação extensível (XML) incluindo um atributo identificador para um período remoto que corresponde aos dados da mídia de anúncio a partir de um streaming adaptativo dinâmico através do cliente HTTP (DASH) do dispositivo do cliente; receber dados para o período remoto através de um transporte de broadcast ou um transporte de multicast; determinar que os dados para o período remoto correspondem ao URL XLink quando dados do transporte de broadcast ou do transporte multicast incluem um valor identificador que corresponde ao valor identificador do URL XLink e,em resposta à determinação de que os dados para o período remoto correspondem ao URL XLink, entregar os dados para o período remoto para o cliente DASH.
[0012] Os detalhes de um ou mais exemplos são apresentados nos desenhos de acompanhamento e na descrição abaixo. Outras características, objetos e vantagens serão evidentes a partir da descrição e desenhos, e a partir das reivindicações.
[0013] A FIG. 1 é um diagrama de blocos que ilustra um sistema exemplar que implementa técnicas para streaming de dados de mídia sobre uma rede.
[0014] A FIG. 2 é um diagrama de blocos que ilustra um conjunto exemplar de componentes da unidade de recuperação da FIG. 1 em maior detalhe.
[0015] A FIG. 3 é um diagrama conceitual ilustrando elementos do conteúdo multimídia exemplar.
[0016] A FIG. 4 é um diagrama de blocos que ilustra outro sistema exemplar que pode implementar as técnicas desta revelação.
[0017] A FIG. 5 é um diagrama de blocos que ilustra outro sistema exemplar que pode implementar as técnicas desta revelação.
[0018] As FIGs. 6A-6B são diagramas de sequência ilustrando vários métodos exemplares nos quais um cliente DASH garante a recepção de conteúdo de anúncio adequado.
[0019] A FIG. 9 é um diagrama conceitual que ilustra um fragmento de Descrição de Filtro exemplar, como definido atualmente, para carregar os dados do filtro de localização.
[0020] A FIG. 10 é um diagrama conceitual que ilustra extensões para o fragmento de Descrição do Filtro para carregar os dados de Preferência & Perfil do Usuário (UP/P).
[0021] As FIGs. 11A e 11B são diagramas de sequência que ilustram um exemplo de método para seleção de anúncio auxiliada por cliente MBMS de acordo com as técnicas desta revelação.
[0022] A FIG. 12 é um diagrama de sequência ilustrando um exemplo de método para a seleção de anúncio auxiliada por cliente MBMS e inserção para Protocolo de Transporte em Tempo Real (RTP), de acordo com as técnicas desta revelação.
[0023] As FIGs. 13A-13D são diagramas conceituais que ilustram uma extensão exemplar para um elemento de Arquivo da tabela de entrega de arquivo (FDT).
[0024] A FIG. 14 é um diagrama de blocos que ilustra outro sistema exemplar 300 que pode realizar as técnicas desta revelação.
[0025] As FIGs. 15A e 15B são diagramas de sequência que ilustram um exemplo de método de acordo com as técnicas desta revelação.
[0026] De um modo geral, esta revelação descreve técnicas para inserção de anúncio publicitário (ad) direcionada. Estas técnicas podem ser usadas quando os dados de mídia do streaming, por exemplo, de acordo com um serviço unicast, broadcast ou multicast, como Serviço de Broadcast Multicast de Multimídia Avançado (eMBMS). Por exemplo, as técnicas desta revelação podem ser utilizadas em conjunto com, ou para aumentar as técnicas de Operação de MBMS Melhorada - Melhorias de MBMS (MI-EMO). MI-EMO é descrita, por exemplo, na Visão Geral do 3 GPP Versão 12 VO.1.1, de dezembro de 2013, disponível em http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_R eleases/Rel-12_description_20131224.zip. Estas técnicas também podem ser usadas em MBMS melhorado (eMBMS), descrito na Operação de MBMS Melhorada, 3 GPP TR 26.848 v. 12.0.0 (dezembro de 2014), disponível em www.3gpp.org/ftp/Specs/archive/26_series/26.848/26848- c00.zip, e/ou Protocolos e Codecs de MBMS, 3GPPTS 26.346 v. 12.4.0 (dezembro de 2014), disponível em www.3gpp.org/ftp/Specs/archive/26_series/26.346/26346- c40.zip.
[0027] As técnicas desta revelação podem ser utilizadas de acordo com o seguinte exemplo de caso de uso de MI-EMO: Dois dos principais times de futebol de uma cidade povoada vão jogar uma partida de competição um contra o outro no fim de semana. Já que se espera que o jogo gere um grande interesse entre os fãs, a operadora pretende oferecer o serviço sobre MBMS aos seus assinantes. A operadora planeja entregar conjuntos separados de anúncios direcionados para os fãs do clube, isto é, a serem reproduzidos durante os intervalos do jogo, etc., para promover os produtos das lojas dos fãs de cada clube de futebol, compartilhando notícias relacionadas ao clube, etc.
[0028] As técnicas desta revelação podem suportar a inserção de anúncio direcionado no MBMS e eMBMS. As técnicas da presente revelação podem ser utilizadas para broadcast o conteúdo principal e anúncios, e permitir a inserção de anúncios direcionados com o suporte de um elemento de cliente de download (por exemplo, um elemento de software, um elemento de hardware, ou uma combinação de hardware e software). Para eventos ao vivo (isto é, conteúdo de mídia capturado ao vivo que é transmitido em sequência o mais rapidamente possível após a captura, codificação e empacotamento), as técnicas da presente revelação podem permitir a programação da entrega de anúncios direcionados de modo que os anúncios possam ser inseridos no conteúdo principal em tempo real. As técnicas da presente divulgação também podem permitir que um cliente MBMS receba seletivamente anúncios entregues através de MBMS de acordo com as características do usuário. Tais características de usuário podem corresponder às informações armazenadas em um repositório de dados de Usuário/Preferência/Perfil, por exemplo, armazenados em um dispositivo cliente
[0029] As técnicas desta revelação podem ser aplicadas quando as seguintes restrições estão em vigor: A entrega de conteúdo de anúncio direcionada sobre MBMS só pode ser possível através do envio de todos os recursos relacionados à anúncio em relação à mesma Entrega de Arquivos sobre a sessão de Transporte Unidirecional (FLUTE) na mesma Identidade de Grupo Móvel Temporária (TMGI). Em seguida, a recepção pode ser feita com uma abordagem promíscua como definido na seção 7.2 da TS 26.346 devido a uma possível incapacidade de associar o conteúdo do anúncio a um grupo específico identificado por traços específicos de usuário. A TS 26.346 é descrito na Projeto de Parceria para a 3a Geração; Serviços de Grupo de Especificação Técnica e Aspectos do Sistema; Serviço Broadcast/Multicast de Multimídia (MBMS); Protocolos e Codecs (Versão 12); V12.0.0; dezembro de 2013, disponível em http://www.3gpp.org/DynaReport/26234.htm. De modo similar, as técnicas desta revelação podem ser usadas quando as seguintes restrições adicionais ou alternativas estão em vigor: Pode não ser possível permitir que clientes de MBMS recebam seletivamente conteúdo de anúncio entregue através de MBMS de acordo com as características do usuário, a fim de permitir uma operação de uma cópia para instruir FLUTE a receber uma cópia de um ou mais arquivos específicos (identificados pelo fileURI ou potencialmente outros padrões). As técnicas desta revelação também podem ser aplicadas para proporcionar a inserção de comerciais direcionados para a entrega de streaming do Protocolo de Transporte em Tempo Real (RTP) através de MBMS.
[0030] Em geral, esta divulgação descreve três técnicas exemplares para suportar a inserção do anúncio direcionado. Uma primeira técnica exemplar refere-se à seleção do anúncio baseada no aplicativo. Uma segunda técnica exemplar é direcionada à seleção de anúncio com base no servidor, por exemplo, incluindo um de streaming adaptativo dinâmico sobre o cliente HTTP (DASH). Em um terceiro exemplo de técnica, um cliente MBMS auxilia na seleção do anúncio. Detalhes adicionais destas técnicas exemplar, e espécies, combinações e subcombinações dos mesmos, são descritos em maior detalhe abaixo.
[0031] Em alguns exemplos, ao receber o conteúdo de mídia usando broadcast ou multicast, um cliente MBMS ou cliente eMBMS pode receber o conteúdo de mídia, em seguida, tornar o conteúdo de mídia disponível para um cliente de streaming, como um cliente DASH. O cliente DASH pode recuperar o conteúdo de mídia a partir do cliente MBMS utilizando, por exemplo, operações de recuperação de HTTP. Em streaming de HTTP, como o DASH, operações mais frequentes incluem HEAD, GET, e GET parcial. A operação HEAD recupera um cabeçalho de um arquivo associado a um determinado localizador de recurso uniforme (URL) ou nome de recursos uniforme (URN), sem recuperar uma carga útil associada com o URL ou URN. A operação GET recupera um arquivo inteiro associado a um determinado URL ou URN. A operação GET parcial recebe uma faixa de bytes como um parâmetro de entrada e recupera um número contínuo de bytes de um arquivo, em que o número de bytes corresponde à faixa de byte recebida. Assim, fragmentos de filmes podem ser fornecidos para streaming de HTTP, porque uma operação GET parcial pode obter um ou mais fragmentos de filmes individuais. Em um fragmento de filme, pode haver vários fragmentos de faixa de diferentes faixas. No streaming de HTTP, uma apresentação de mídia pode ser uma coleta estruturada de dados que é acessível ao cliente. O cliente pode solicitar e baixar informações de dados de mídia para apresentar um serviço de streaming a um usuário.
[0032] No exemplo de streaming de dados 3GPP que usa streaming de HTTP, pode haver múltiplas representações para dados de vídeo e/ou de áudio do conteúdo multimídia. Como explicado abaixo, diferentes representações podem corresponder a diferentes características de codificação (por exemplo, diferentes perfis ou níveis de um padrão de codificação de vídeo), diferentes padrões ou extensões de codificação dos padrões de codificação (como extensões de multivista e/ou escaláveis), ou diferentes taxas de bits. O manifesto de tais 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 coleta estruturada de dados que é acessível a um dispositivo do cliente de streaming de HTTP. O dispositivo do cliente de streaming de HTTP pode solicitar e baixar informações de dados de mídia para apresentar um serviço de streaming a um usuário do dispositivo do cliente. Uma apresentação de mídia pode ser descrita na estrutura de dados MPD, que pode incluir atualizações de MPD.
[0033] Uma apresentação em mídia pode conter uma sequência de um ou mais períodos. Os períodos podem ser definidos por um elemento de Período na MPD. Cada período pode ter um início atributo na MPD. A MPD pode incluir um atributo de início e um atributo de StartTime disponível para cada período. Para serviços ao vivo, a soma do atributo de partida do período e o atributo de MPD availableStartTime podem especificar o tempo de disponibilidade do período no formato UTC, em particular o primeiro Segmento de Mídia de cada representação no período correspondente. Para os serviços sob demanda, o atributo de início do primeiro período pode ser 0. Para qualquer outro período, o atributo de início pode especificar um deslocamento de tempo entre a hora de início do período correspondente em relação à hora de início do primeiro período. Cada período pode ir até ao início do próximo Período, ou até ao fim da apresentação de mídia, no caso do último período. Os tempos de partida de época pode ser precisos. Eles podem refletir a temporização real resultante da reprodução da mídia de todos os períodos anteriores.
[0034] Cada período pode conter uma ou mais representações para o mesmo conteúdo de mídia. Uma representação pode ser uma de uma série de versões codificadas alternativas de dados de áudio ou de vídeo. As representações podem diferir por tipos de codificação, por exemplo, pela taxa de bits, resolução e/ou codec de dados de vídeo e taxa de bit, idioma e/ou codec para dados de áudio. O termo representação pode ser utilizado para se referir a uma seção de dados de áudio ou de vídeo codificados correspondentes a um período particular do conteúdo de multimídia codificado de uma maneira específica.
[0035] Representações de um período específico podem ser atribuídas a um grupo indicado por um atributo no MPD indicativo de um conjunto de adaptação ao qual as representações pertencem. Representações no mesmo conjunto de adaptação são geralmente consideradas como substitutas uma para a outra, em que um dispositivo cliente pode dinamicamente e facilmente alternar entre essas representações, por exemplo, para realizar a adaptação da largura de banda. Por exemplo, cada representação dos dados de vídeo para um determinado período pode ser atribuída ao mesmo conjunto de adaptação, de modo que qualquer uma das representações pode ser selecionada para decodificação para apresentar dados multimídia, como dados de vídeo ou dados de áudio, do conteúdo multimídia para o período correspondente. O conteúdo de mídia dentro de um período pode ser representado por qualquer representação do grupo 0, se presente, ou a combinação de, no máximo, uma representação de cada grupo diferente de zero, em alguns exemplos. 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.
[0036] 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 de auto-inicialização. Quando presente, o segmento de inicialização pode conter informação de inicialização para acessa a representação. Em geral, o segmento de inicialização não contém dados de mídia. Um segmento pode ser referido unicamente por um identificador, como um localizador de recurso uniforme (URL), nome do recurso uniforme (URN), ou identificador de recurso uniforme (URI). A MPD pode fornecer os identificadores para cada segmento. Em alguns exemplos, a MPD também pode fornecer faixas de bytes na forma de um atributo de faixa, que pode corresponder aos dados para um segmento dentro de um arquivo acessível pelo URL, URN ou URI.
[0037] Diferentes representações podem ser selecionadas para a recuperação substancialmente simultânea de diferentes tipos de dados de mídia. Por exemplo, um dispositivo cliente pode selecionar uma representação de áudio, uma representação de vídeo, e uma representação de texto cronometrada a partir da qual recuperar segmentos. Em alguns exemplos, o dispositivo cliente pode selecionar conjuntos específicos de adaptação para realizar a adaptação da 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 cronometrado. 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 cronometrado).
[0038] A FIG. 1 é um diagrama de blocos que ilustra um sistema exemplar 10 que implementa técnicas para streaming de dados de mídia sobre 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 dispositivo servidor 60 estão acoplados de forma comunicativa pela rede 74, que pode compreender a Internet. Em alguns exemplos, o dispositivo de preparação de conteúdo 20 e dispositivo servidor 60 também podem ser acoplados pela rede 74 ou outra rede, ou podem ser diretamente acoplados comunicativamente. Em alguns exemplos, o dispositivo de preparação de conteúdo 20 e dispositivo servidor 60 podem compreender o mesmo dispositivo.
[0039] O dispositivo de preparação de conteúdo 20, no exemplo da FIG. 1, compreende fonte de áudio 22 e fonte de vídeo 24. A fonte de áudio 22 pode compreender, por exemplo, um microfone que produz sinais elétricos representativos de dados de áudio capturados a serem codificados pelo codificador de áudio 26. Alternativamente, a fonte de áudio 22 pode compreender uma mídia de armazenamento que armazena os dados de áudio previamente registados, um gerador de dados de áudio, 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 a serem codificados por um codificador de vídeo 28, uma mídia de armazenamento codificada com dados de vídeo previamente gravados, uma unidade de geração de dados de vídeo, 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 é necessariamente acoplado comunicativamente ao dispositivo servidor 60 em todos os exemplos, mas pode armazenar o conteúdo multimídia para uma mídia separada que é lida pelo dispositivo servidor 60.
[0040] Os dados de áudio e dados de vídeo podem compreender dados analógicos ou digitais. Os dados analógicos podem ser digitalizados antes de serem codificados pelo codificador de áudio 26 e/ou codificador de vídeo 28. A fonte de áudio 22 pode obter dados de áudio de um participante que está falando enquanto o participante que está falando está falando, e a fonte de vídeo 24 pode simultaneamente obter dados de vídeo do participante que está falando. Em outros exemplos, a fonte de áudio 22 pode compreender uma mídia de armazenamento legível por computador que compreende os dados de áudio armazenados, e a fonte de vídeo 24 pode compreender uma mídia de armazenamento de leitura por computador que compreende dados de vídeo armazenados. Deste modo, as técnicas descritas na presente revelação podem ser aplicadas aos dados de áudio e vídeo ao vivo, de streaming e em tempo real ou aos dados de áudio e vídeo arquivados, pré- gravados.
[0041] Os quadros de áudio que correspondem aos quadros de vídeo são geralmente quadros de áudio que contém dados de áudio que foram capturados (ou gerados) pela fonte de áudio 22 simultaneamente com dados de vídeo capturados (ou gerados) pela fonte de vídeo 24 que está contida dentro dos quadros de vídeo. Por exemplo, enquanto um participante que está falando geralmente produz dados de áudio pela fala, a fonte de áudio 22 capta os dados de áudio e a fonte de vídeo 24 captura os dados de vídeo do participante que está falando ao mesmo tempo, que é, enquanto a fonte de áudio 22 está capturando os dados de áudio. Assim, um quadro de áudio pode temporalmente corresponder a um ou mais quadros de vídeo específicos. Deste modo, um quadro de áudio correspondente a um quadro de vídeo geralmente corresponde a um estado em que os dados de áudio e dados de vídeo foram capturados ao mesmo tempo e para a qual 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.
[0042] Em alguns exemplos, o codificador de áudio 26 pode codificar uma marca de hora em cada quadro de áudio codificado que representa um momento em que os dados de áudio para o quadro de áudio codificado foram registrados, e de forma semelhante, o codificador de vídeo 28 pode codificar uma marca de hora em cada quadro de vídeo codificado que representa um momento no qual os dados de vídeo do quadro de vídeo codificado foram gravados. Nesses exemplos, um quadro de áudio correspondente a um quadro de vídeo pode compreender um quadro de áudio que compreende uma marca de hora e um quadro de vídeo que compreende a mesma marca de hora. O dispositivo de preparação de conteúdo 20 pode incluir um relógio interno a partir do qual o codificador de áudio 26 e/ou codificador de vídeo 28 pode gerar as marcas de hora, ou que a fonte de áudio 22 e fonte de vídeo 24 pode usar para associar dados de áudio e vídeo, respectivamente, com uma marca de hora.
[0043] Em alguns exemplos, a fonte de áudio 22 pode enviar dados para o codificador de áudio 26 correspondentes a um momento 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 momento 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 ordenação temporal relativa dos dados de áudio codificados mas sem indicar necessariamente um tempo absoluto no qual os dados de áudio foram gravados, e de forma semelhante, um codificador de vídeo 28 também pode utilizar identificadores de sequências para indicar uma ordenação temporal relativa dos dados de vídeo codificados. Do mesmo modo, em alguns exemplos, um identificador de sequência pode ser mapeado ou de outra forma correlacionado com uma marca de tempo.
[0044] O codificador de áudio 26 geralmente produz um fluxo de dados de áudio codificados, enquanto o codificador de vídeo 28 produz um fluxo de dados de vídeo codificados. Cada fluxo individual de dados (seja de áudio ou vídeo) pode ser referido como um fluxo elementar. Um fluxo elementar é um único componente codificado digitalmente (possivelmente comprimido) 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 pacotes (PES), antes de ser encapsulado dentro de um arquivo de vídeo. Dentro da mesma representação, o ID do fluxo pode ser utilizado para distinguir os pacotes PES pertencentes a um fluxo elementar a partir do outro. A unidade básica de dados de um fluxo elementar é um pacote de fluxo elementar empacotado (PES). Assim, os dados de vídeo codificados geralmente correspondem aos fluxos de vídeo elementares. Da mesma forma, os dados de áudio correspondem a um ou mais respectivos fluxos elementares.
[0045] Muitos padrões de codificação de vídeo, como ITU-T H.264 / AVC e o próximo padrão de Codificação de Vídeo de Alta Eficiência (HEVC), definem a sintaxe, semântica e processo de decodificação dos fluxos de bits livres de erros, qualquer um dos quais se adequa a um determinado perfil ou nível. Os padrões de codificação de vídeo geralmente não especificam o codificador, mas o codificador tem a tarefa de garantir que os fluxos de bits gerados são 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 lhes são aplicáveis. Como definido pelo padrão H.264, por exemplo, um “perfil” é um subconjunto de toda a sintaxe do fluxo de bits que é especificada pelo padrão H.264. Um “nível” corresponde às limitações do consumo de recursos do decodificador, como, por exemplo, memória do decodificador e computação, que estão relacionados com a resolução das imagens, taxa de bits e taxa de processamento de bloco. Um perfil pode ser sinalizado com um valor de idc (indicador de perfil) do perfil, enquanto que um nível pode ser sinalizado com um valor de idc (indicador de nível) do nível.
[0046] 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 dos codificadores e decodificadores dependendo dos valores assumidos pelos elementos de sintaxe no fluxo de bits como o tamanho especificado das imagens decodificadas. O padrão H.264 reconhece ainda que, em muitas aplicações, não é nem prático nem econômico implementar um decodificador capaz de lidar com todos os usos hipotéticos da sintaxe dentro de um perfil particular. Assim, o padrão H.264 define um “nível” como um conjunto específico de restrições impostas aos valores dos elementos de sintaxe no fluxo de bit. Estas restrições podem ser simples limites em valores. Alternativamente, estas restrições podem assumir a forma de restrições sobre combinações aritméticas de valores (por exemplo, largura da imagem multiplicada pela altura da imagem multiplicado pelo número de imagens decodificadas por segundo). O padrão H.264 prevê ainda que implementações individuais podem suportar um nível diferente para cada perfil suportado.
[0047] Um decodificador de acordo com um perfil normalmente suporta todas as características definidas no perfil. Por exemplo, como uma característica de codificação, a codificação da imagem B não é suportada no perfil da linha base do H.264/AVC, mas é suportada em outros perfis de H.264/AVC. Um decodificador de acordo com um nível deve ser capaz de decodificar qualquer fluxo de bits que não requer recursos além das limitações definidas no nível. As definições dos perfis e níveis pode ser útil para facilidade de interpretação. Por exemplo, durante a transmissão de vídeo, um par de definições de perfil e nível pode ser negociado e acordado para uma sessão de transmissão inteira. Mais especificamente, em H.264/AVC, um nível pode definir limitações sobre o número de macroblocos que precisam ser processados, tamanho do buffer da imagem decodificada (DPB), buffer da imagem codificada (CEC), faixa de vetor de movimento vertical, número máximo de vetores de movimento por dois MBs consecutivos, e se um bloco B pode ter partições de sub-macrobloco menores que 8x8 pixels. Desta maneira, um decodificador pode determinar se o decodificador é capaz de decodificar corretamente o fluxo de bits.
[0048] No exemplo da FIG. 1, a unidade de encapsulamento 30 do dispositivo de preparação de conteúdo 20 recebe fluxos elementares que compreendem dados de vídeo codificados do codificador de vídeo 28 e fluxos elementares que compreendem dados de áudio codificados do codificador de áudio 26. Em alguns exemplos, o codificador de vídeo 28 e o codificador de áudio 26 podem cada incluir empacotadores para formar pacotes PES a partir de dados codificados. Em outros exemplos, o codificador de vídeo 28 e o codificador de áudio 26 podem cada 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 de dados de áudio e vídeo codificados.
[0049] O codificador de vídeo 28 pode codificar dados de vídeo de conteúdo multimídia de várias maneiras, para produzir diferentes representações do conteúdo multimídia em várias taxas de bits e com várias características, como resoluções de pixel, taxas de quadros, conformidade aos vários padrões de codificação, conformidade aos vários perfis e/ou níveis de perfil para vários padrões de codificação, representações tendo um ou vários modos de exibição (por exemplo, para reprodução bidimensional ou tridimensional), ou outras dessas características. Uma representação, como utilizada na presente revelação, pode compreender um dos dados de áudio, dados de vídeo, dados de texto (por exemplo, para as legendas fechadas), ou outros dados semelhantes. A representação pode incluir um fluxo elementar, como um fluxo elementar de áudio ou um fluxo elementar de vídeo. Cada pacote PES pode incluir uma ID de fluxo que identifica o fluxo elementar ao qual pertence o pacote PES. A unidade de encapsulamento 30 é responsável pela montagem de fluxos elementares em arquivos de vídeo (por exemplo, segmentos) de diferentes representações.
[0050] A unidade de encapsulamento 30 recebe pacotes PES para fluxos elementares de uma representação do codificador de áudio 26 e codificador de vídeo 28 e forma unidades de camada de abstração de rede correspondentes (NAL) a partir dos pacotes PES. No exemplo do H.264/AVC (Codificação de Vídeo Avançada), segmentos de vídeo codificados são organizados em unidades NAL, que fornecem uma representação de vídeo “amigável à rede” abordando aplicações como telefonia de vídeo, armazenamento, broadcast ou streaming. As unidades NAL podem ser categorizadas para unidades NAL de Camada de Codificação de Vídeo (VCL) e unidades NAL não-VCL. As unidades de VCL podem conter o motor de compressão de núcleo e podem incluir bloco, macrobloco, e/ou dados do nível de fatia. Outras unidades NAL podem ser unidades NAL não-VCL. Em alguns exemplos, uma imagem codificada em um instante de tempo, normalmente apresentada como uma imagem primária codificada, pode estar contida em uma unidade de acesso, que pode incluir uma ou mais unidades NAL.
[0051] As unidades NAL não-VCL podem incluir unidades NAL de conjunto de parâmetro e unidades NAL SEI, entre outras. Os conjuntos de parâmetros podem conter informações de cabeçalho de nível sequência (em conjuntos de parâmetros de sequência (SPS)) e as informações de cabeçalho de nível de imagem raramente em modificação (nos conjuntos de parâmetros de imagem (PPS)). Com conjuntos de parâmetros (por exemplo, PPS e SPS), as informações que raramente mudam não precisam ser repetidas para cada sequência ou imagem, portanto, a eficiência da codificação pode ser melhorada. Além disso, o uso de conjuntos de parâmetros pode permitir a transmissão fora da banda da informação de cabeçalho importante, evitando a necessidade de transmissões redundantes para a resiliência de erro. Nos exemplos de transmissão fora de banda, as unidades NAL do conjunto de parâmetro podem ser transmitidas em um canal diferente do que outras unidades NAL, como unidades NAL SEI.
[0052] As Informações de Melhoramento 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 ajudar em processos relacionados à decodificação, exibição, resiliência de erro, e outros fins. 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 aplicação do decodificador compatível ao padrão. As mensagens SEI podem ser mensagens SEI de nível de sequência ou mensagens SEI de nível de imagem. Algumas informações sobre o nível de sequência podem estar contidas em mensagens SEI, como mensagens SEI de informações de escalabilidade no exemplo de SVC e mensagens de informação de escalabilidade de vista na MVC. Estas mensagens SEI exemplares podem transmitir informações sobre, por exemplo, a extração de pontos de funcionamento e características dos pontos de operação. Além disso, a unidade de encapsulamento 30 pode formar um arquivo de manifesto, 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).
[0053] 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 interface de saída 32. A interface de saída 32 pode compreender uma interface de rede ou uma interface para gravar em uma mídia de armazenamento, como uma interface de barramento em série universal (USB), um gravador de CD ou DVD, uma interface para mídias de armazenamento magnéticas ou flash, ou outras interfaces para armazenar ou transmitir 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, o que pode enviar os dados para o dispositivo servidor 60 através da transmissão de rede ou mídia de armazenamento. No exemplo da FIG. 1, o dispositivo servidor 60 inclui mídia de armazenamento 62 que armazena vários conteúdos multimídia 64, cada uma 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 também pode enviar dados diretamente para a rede 74.
[0054] Em alguns exemplos, as representações 68 podem ser separadas em conjuntos de adaptação. Ou seja, vários subconjuntos de representações 68 podem incluir respectivos conjuntos comuns de características, como codec, perfil e nível, resolução, número de vistas, formato de arquivo para segmentos, informações de tipo de texto que podem identificar uma linguagem ou outras características do texto a serem apresentadas com a representação e/ou dados de áudio a serem decodificados e apresentados, por exemplo, por alto falantes, informações de ângulo de câmera que podem descrever um ângulo da câmera ou perspectiva da câmera do mundo real de um cenário para representações no conjunto de adaptação, informações de classificação que descrevem a adequação do conteúdo para públicos específicos, ou semelhantes.
[0055] O arquivo de manifesto 66 pode incluir dados indicativos dos subconjuntos de representações 68 correspondentes a determinados conjuntos de adaptação, bem como características comuns para os conjuntos de adaptação. O arquivo de manifesto 66 também pode incluir dados representativos das características individuais, como taxas de bits, para as representações individuais de conjuntos de adaptação. Desta forma, um conjunto de adaptação pode fornecer uma adaptação da largura de banda da rede simplificada. Representações em um conjunto de adaptação podem ser indicadas através de elementos filho de um elemento do conjunto de adaptação do arquivo de manifesto 66.
[0056] O dispositivo de servidor 60 inclui a unidade de processamento de pedido 70 e interface de rede 72. Em alguns exemplos, o dispositivo servidor 60 pode incluir uma pluralidade de interfaces de rede. Além disso, todo e qualquer recurso do dispositivo servidor 60 pode ser implementado em outros dispositivos de uma rede de entrega de conteúdo, como roteadores, pontes, dispositivos de proxy, comutadores, ou outros dispositivos. Em alguns exemplos, os dispositivos intermediários de uma rede de entrega de conteúdo podem armazenar em cache dados de conteúdos multimídia 64, e incluir componentes que substancialmente se adequam com aqueles do dispositivo servidor 60. Em geral, a interface de rede 72 é configurada para enviar e receber dados através da rede 74.
[0057] A unidade de processamento de pedido 70 é configurada para receber solicitações de rede de dispositivos clientes, como dispositivo cliente 40, para os dados da mídia de armazenamento 62. Por exemplo, a unidade de processamento de pedido 70 pode implementar o protocolo de transferência de hipertexto (HTTP) versão 1.1, conforme descrito em RFC 2616, “Hypertext Transfer Protocol - HTTP/1.1” por R. Fielding et al, Grupo de Trabalho de Rede, IETF, Junho de 1999. Ou seja, a unidade de processamento de pedido 70 pode ser configurada para receber pedidos GET de HTTP ou GET parciais e fornecer dados de conteúdos multimídia 64, em resposta aos pedidos. Os pedidos podem especificar um segmento de uma das representações 68, por exemplo, utilizando uma URL do segmento. Em alguns exemplos, os pedidos também podem especificar uma ou mais faixas de bytes do segmento, compreendendo assim solicitações GET parciais. A unidade de processamento de pedido 70 pode ainda ser configurada para pedidos HEAD de HTTP de serviço para fornecer dados de cabeçalho de um segmento de uma das representações 68. Em qualquer caso, a unidade de processamento do pedido 70 pode ser configurada para processar os pedidos para fornecer dados solicitados para um dispositivo solicitante, como dispositivo cliente 40.
[0058] Adicional ou alternativamente, a unidade de processamento de pedido 70 pode ser configurada para entregar dados de mídia através de um protocolo de broadcast ou multicast, como eMBMS. Dispositivo de preparação de conteúdo 20 pode criar segmentos e/ou sub- segmentos DASH substancialmente da mesma maneira como descrito, mas o dispositivo servidor 60 pode fornecer estes segmentos ou sub-segmentos usando eMBMS ou outro protocolo de transporte de rede de broadcast ou multicast. Por exemplo, a unidade de processamento de pedido 70 pode ser configurada para receber um pedido de participação do grupo multicast a partir do dispositivo cliente 40. Ou seja, o dispositivo servidor 60 pode anunciar um endereço de protocolo da Internet (IP) associado a um grupo multicast para dispositivos clientes, incluindo o dispositivo cliente 40, associado com conteúdo de mídia específico (por exemplo, uma transmissão de um evento ao vivo). O dispositivo cliente 40, por sua vez, pode apresentar um pedido para se juntar ao grupo multicast. Esse pedido pode ser propagado em toda a rede 74, por exemplo, os roteadores que compõem a rede 74, de modo que faz-se com que os roteadores direcionem o tráfego destinado para o endereço IP associado ao grupo de multicast aos dispositivos clientes assinantes, como o dispositivo cliente 40.
[0059] Como ilustrado no exemplo da FIG. 1, o conteúdo multimídia 64 inclui 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 alternativas 68 (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 o MPD de uma apresentação de mídia para determinar como acessar segmentos de representações 68.
[0060] Em particular, a unidade de recuperação 52 (que pode implementar as técnicas desta revelação) pode recuperar os dados de configuração (não representados) do dispositivo cliente 40 para determinar as capacidades de decodificação do decodificador de vídeo 48 e capacidades de renderização da saída de vídeo 44. Os dados de configuração também podem incluir qualquer um ou todos de uma preferência de linguagem selecionada por um usuário do dispositivo cliente 40, uma ou mais perspectivas de câmara 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 de 52 pode compreender, por exemplo, um navegador da Web ou um cliente de mídia configurado para enviar solicitações GET e de GET parcial do HTTP. A unidade de recuperação 52 pode corresponder às instruções de software executadas por um ou mais processadores ou unidades de processamento (não mostradas) do dispositivo cliente 40. Em alguns exemplos, todas ou partes da funcionalidade descrita com relação à unidade de recuperação 52 podem ser implementadas em hardware, ou uma combinação de hardware, software e/ou firmware, onde o hardware do requisito pode ser fornecido para executar instruções para o software ou firmware.
[0061] A unidade de recuperação 52 pode comparar as capacidades de decodificação e de renderização do dispositivo cliente 40 às características de representações 68 indicadas pelas informações do arquivo de manifesto 66. A unidade de recuperação 52 pode inicialmente recuperar pelo menos uma porção do arquivo de manifesto 66 para determinar as características de representações 68. Por exemplo, a unidade de recuperação 52 pode solicitar uma porção 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) que tem características que podem ser satisfeitas pelas capacidades 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 um montante atualmente disponível da largura de banda de rede e retirar segmentos de uma das representações que têm uma taxa de bits que pode ser satisfeita pela largura de banda da rede.
[0062] Em geral, representações de taxa de bits mais elevadas podem produzir a reprodução de vídeo de qualidade superior, enquanto representações de taxa de bit inferior podem oferecer uma reprodução de vídeo com qualidade suficiente quando a largura de banda disponível da rede diminui. Assim, quando a largura de banda de rede disponível é relativamente alta, a unidade de recuperação 52 pode recuperar dados de representações de taxas de bits relativamente altas, enquanto que quando a largura de banda disponível da rede é baixa, a unidade de recuperação 52 pode recuperar dados de representações taxas de bits relativamente baixas. Desta forma, o dispositivo cliente 40 pode transmitir dados multimídia através da rede 74, enquanto também se adapta às mudanças da disponibilidade de largura de banda de rede 74.
[0063] Adicional ou alternativamente, a unidade de recuperação 52 pode ser configurada para receber dados de acordo com um protocolo de rede de broadcast ou multicast, como eMBMS ou multicast IP. Nesses exemplos, a unidade de recuperação 52 pode apresentar um pedido para se juntar a um grupo de rede multicast associado com conteúdo de mídia específico. Depois de entrar para o grupo multicast, a unidade de recuperação 52 pode receber dados do grupo multicast sem pedidos adicionais emitidos para o dispositivo servidor 60 ou dispositivo de preparação de conteúdos 20. A unidade de recuperação 52 pode apresentar um pedido para deixar o grupo multicast quando os dados do grupo multicast não forem mais necessários, por exemplo, para interromper a reprodução ou para mudar canais para um grupo multicast diferente.
[0064] Em uma primeira técnica exemplar da presente revelação (seleção de publicidade à base de aplicativo), a unidade de recuperação 52 (ou outro elemento do dispositivo cliente 40, como um aplicativo de cliente de um cliente DASH, que pode fazer parte da unidade de recuperação 52) pode realizar a seleção de anúncio direcionada, sem a assistência do cliente DASH ou de uma camada de serviço MBMS. Neste exemplo, a inteligência para a seleção de anúncios reside em ou é da responsabilidade deste aplicativo, que pode envolver a interação com outros facilitadores de serviços não especificados por um padrão aplicável, como o 3GPP TS 26.346 (Protocolos e codes do Serviço de Broadcast/Multicast Multimídia (MBMS)). Este exemplo pode permitir diferentes técnicas de entrega com base em HTTP, por exemplo, o uso de cache e/ou cookies. Neste exemplo, a camada de serviço MBMS pode simplesmente fornecer a entrega de anúncio. O cliente DASH pode simplesmente buscar uma MPD como instruído pelo aplicativo. Este exemplo pode ser modelado após a estrutura de inserção de anúncio concebida pelo DASH-IF (DASH Industry Forum). Mais detalhes desta primeira técnica exemplar são descritos em relação à FIG. 4 abaixo.
[0065] Em um segundo conjunto exemplar de técnicas desta revelação (a seleção de publicidade baseada em servidor, incluindo o cliente DASH), a unidade de recuperação 52 pode incluir um cliente DASH que realiza a seleção de anúncio direcionada, com a ajuda de dispositivos de rede 74 (por exemplo, dispositivo servidor 60, dispositivo de preparação de conteúdo 20, ou outro dispositivo não representado na FIG. 1). Em geral, a rede 74 inclui um dispositivo que emprega um mecanismo de evento DASH para fazer com que o cliente DASH da unidade de recuperação 52 busque uma MPD atualizada, que contém metadados para afetar uma determinação de anúncio. Ambos modos nominais e aprimorados podem ser empregados, quanto a saber se um cliente MBMS da unidade de recuperação 52 faz o download de todos os anúncios, ou somente de anúncios selecionados. Esta técnica pode ser modelada após uma estrutura de inserção de anúncio concebida pelo DASH-IF. Vários aspectos das técnicas de acordo com este segundo exemplo são descritos com relação às FIGs. 5 a 8B.
[0066] Embora o mecanismo de evento DASH para atualizar a MPD tenha sido descrito para propósitos de exemplo, deve ser entendido que a utilização do mecanismo de evento DASH não é obrigatória para permitir a entrega/aquisição de uma MPD atualizada (onde a MPD atualizada contém um elemento de Período remoto que descreve os segmentos de anúncio (ad) que serão buscados durante a ponto de inserção/junção no programa). Uma função equivalente também poderia ser fornecida pela sinalização das atualizações de MPD esperadas periódicas (sinalizadas pela MPD@minimumUpdatePeriod), com uma frequência suficientemente elevada, de modo que o cliente DASH, mantendo a verificação para atualizações da MPD, não vai perder a ocorrência dinâmica do intervalo do Ad. Um exemplo da utilização de tal período mínimo de atualização é descrito em relação ao método das FIGs. 15A-15B abaixo.
[0067] Em um terceiro exemplo de técnica (a seleção de anúncio assistida por cliente MBMS), um cliente MBMS da unidade de recuperação 52 executa a seleção do anúncio baseado no processamento de metadados contidos em uma Descrição de Serviço do Usuário (USD). A inteligência e controle da seleção do anúncio podem ser assumidas por residir unicamente no cliente MBMS da unidade de recuperação 52, neste exemplo. O cliente MBMS pode baixar seletivamente e pré armazenar em cache os anúncios, antes da entrega do programa de streaming. Este exemplo representa um mecanismo de personalização de conteúdo que não está restrito a DASH como um serviço de aplicativo. Assim, esta terceira técnica exemplar pode ser igualmente aplicável a, e operar de uma forma comum para, a entrega do serviço de streaming com base no Protocolo de Transporte em Tempo Real (RTP). Vários aspectos das técnicas de acordo com este terceiro exemplo são descritos com relação às FIGs. 9 a 11B.
[0068] 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 fornece os segmentos para a unidade de desencapsulação 50. A unidade de desencapsulação 50 pode desencapsular elementos de um arquivo de vídeo em fluxos PES constituintes, desempacotar os fluxos PES para recuperar dados codificados, e enviar os dados codificados ou para o decodificador de áudio 46 ou decodificador de vídeo 48, dependendo se os dados codificados são parte de uma sequência de áudio ou vídeo, por exemplo, como indicado por cabeçalhos dos pacotes PES do fluxo. O decodificador de áudio 46 decodifica os 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 os dados de vídeo codificados e envia os dados de vídeo decodificados, que podem incluir uma pluralidade de vistas de um fluxo, para a saída de vídeo 44.
[0069] O 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 a unidade de desencapsulação 50 cada um pode ser implementado como qualquer um de uma variedade de circuitos de processamento adequados, conforme o caso, como um ou mais microprocessadores, processadores sinal digital (DSPs), circuitos integrados de aplicação específica (ASICs), arranjos de portas programáveis em campo (FPGA), circuitos lógicos discretos, software, hardware, firmware ou quaisquer suas combinações. Cada codificador de vídeo 28 e decodificador de vídeo 48 pode ser incluído em um ou mais codificadores ou decodificadores, cada um dos quais pode ser integrado como parte de um codificador/decodificador de vídeo combinados (codec). Do mesmo modo, cada um do codificador de vídeo 26 e decodificador de vídeo 46 pode ser incluído em um ou mais codificadores ou decodificadores, cada um dos quais pode ser integrado como parte de um CODEC combinado. Um equipamento, incluindo um codificador de vídeo 28, decodificador de vídeo 48, codificador de áudio 26, decodificador de áudio 46, unidade de encapsulação 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, como um telefone celular.
[0070] O dispositivo cliente 40, dispositivo servidor 60, e/ou dispositivo de preparação de conteúdo 20 podem ser configurados para operar de acordo com as técnicas desta revelação. Para fins de exemplo, esta revelação descreve estas técnicas no que diz respeito ao dispositivo cliente 40 e dispositivo servidor 60. No entanto, deve ser compreendido que o dispositivo de preparação de conteúdo 20 pode ser configurado para executar estas técnicas, em vez de (ou além do) dispositivo servidor 60.
[0071] A unidade de encapsulação 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 descreve o fluxo de transporte ou de programa ao qual a unidade NAL corresponde. Por exemplo, em H.264/AVC, uma unidade NAL inclui um cabeçalho de 1-byte e uma carga útil de tamanho variável. Uma unidade NAL incluindo dados de vídeo 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 encapsulação 30 pode receber dados vídeo codificados 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.
[0072] A unidade de encapsulamento 30 também pode montar unidades de acesso a partir de uma pluralidade de unidades NAL. Em geral, uma unidade de acesso pode compreender uma ou mais unidades NAL para representar um quadro de dados de vídeo, como também dados de áudio correspondentes ao quadro quando tais dados de áudio estão disponíveis. Uma unidade de acesso geralmente inclui todas as unidades NAL para um instante de tempo de saída, por exemplo, todos os dados de áudio e vídeo para um instante de tempo. Por exemplo, se cada vista tem uma taxa de quadro de 20 quadros por segundo (fps), em seguida, cada instante de tempo pode corresponder a um intervalo de tempo de 0,05 segundos. Durante este intervalo de tempo, os quadros específicos para todas as vistas da mesma unidade de acesso (o mesmo instante de tempo) podem ser processados simultaneamente. Em um exemplo, uma unidade de acesso pode compreender uma imagem codificada em um instante de tempo, que pode ser apresentado como uma imagem codificada primária.
[0073] Consequentemente, uma unidade de acesso pode compreender todos os quadros de áudio e de vídeo de um instante temporal comum, por exemplo, todas as vistas correspondentes ao momento X. Esta revelação também se refere a uma imagem codificada de uma vista específica como um “componente de visualização”. Ou seja, um componente de visualização pode incluir uma imagem codificada (ou quadro) para uma vista específica em um momento específico. Assim, uma unidade de acesso pode ser definida como compreendendo todos os componentes de visualização de um instante temporal comum. A ordem de decodificação das unidades de acesso não precisa ser necessariamente a mesma que a de saída ou ordem de exibição.
[0074] Uma apresentação de mídia pode incluir uma descrição de apresentação de mídia (MPD), a qual pode conter descrições de diferentes representações alternativas (por exemplo, serviços de vídeo com diferentes qualidades) e a descrição pode incluir, por exemplo, informações de codec, um valor de perfil, e um valor do nível. Uma MPD é um exemplo de um arquivo de manifesto, como o arquivo de manifesto 66. O dispositivo cliente 40 pode recuperar o MPD de uma apresentação de mídia para determinar como acessar fragmentos de filme das várias apresentações. Os fragmentos de filme podem ser localizados nas caixas de fragmento de filme (moof boxes) dos arquivos de vídeo.
[0075] O arquivo de manifesto 66 (o qual pode compreender, por exemplo, uma MPD) pode anunciar a disponibilidade dos segmentos das representações 68. Ou seja, a MPD pode incluir informações que indicam o tempo do relógio de parede no qual um primeiro segmento de uma das representações 68 se torna disponível, assim como a informação que indica as durações dos segmentos dentro das representações 68. Desta 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 assim como as durações dos segmentos que precedem um segmento específico.
[0076] Após a unidade de encapsulamento 30 ter montado unidades NAL e/ou unidades de acesso em um arquivo de vídeo com base nos dados recebidos, a unidade de encapsulamento 30 passa o arquivo de vídeo para interface de saída 32 para a saída. Em alguns exemplos, a unidade de encapsulação 30 pode armazenar o arquivo de vídeo localmente ou enviar o arquivo de vídeo para um servidor remoto 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 gravação de dados em uma mídia legível por computador, como, por exemplo, uma unidade ótica, uma unidade de mídia magnética (por exemplo, unidade de disquete), um barramento em série universal (USB), uma interface de rede, ou outra interface de saída. A interface de saída 32 emite o arquivo de vídeo para uma mídia legível por computador 34, como, por exemplo, um sinal de transmissão, uma mídia magnética, uma mídia ótica, uma memória, uma unidade flash ou outra mídia legível por computador.
[0077] A interface de rede 54 pode receber uma unidade NAL ou unidade de acesso através da rede 74 e fornecer a unidade NAL ou unidade de acesso para a unidade de desencapsulação 50, através da unidade de recuperação 52. A unidade de desencapsulação 50 pode desencapsular elementos de um arquivo de vídeo em fluxos PES constituintes, desempacotar os fluxos PES para recuperar dados codificados, e enviar os dados codificados ou para o decodificador de áudio 46 ou decodificador de vídeo 48, dependendo se os dados codificados são parte de uma sequência de áudio ou vídeo, por exemplo, como indicado por cabeçalhos dos pacotes PES do fluxo. O decodificador de áudio 46 decodifica os 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 os dados de vídeo codificados e envia os dados de vídeo decodificados, que podem incluir uma pluralidade de vistas de um fluxo, para a saída de vídeo 44.
[0078] A FIG. 2 é um diagrama de blocos que ilustra um conjunto exemplar de componentes da unidade de recuperação da FIG. 1 em maior detalhe. Neste exemplo, a unidade de recuperação 52 inclui a unidade de middleware de eMBMS 100, cliente DASH 110, e aplicativo de mídia 112.
[0079] A unidade de middleware de eMBMS 100 inclui ainda unidade de recepção de eMBMS 106, cache 104, e servidor de proxy 102. Neste exemplo, a unidade de recepção de eMBMS 106 é configurada para receber dados através de eMBMS, por exemplo, de acordo com a Entrega de Arquivo sobre Transporte Unidirecional (FLUTE), descrito em T. Paila et al., “FLUTE— File Delivery over Unidirectional Transport”, Network Working Group, RFC 6726, Nov. 2012, disponível em http://tools.ietf.org/html/rfc6726. Isto é, a unidade de recepção de eMBMS 106 pode receber arquivos através de broadcast a partir de, por exemplo, o dispositivo servidor 60, que pode agir como um BM-SC.
[0080] Na medida em que a unidade de middleware de eMBMS 100 recebe dados para arquivos, a unidade de middleware de eMBMS pode armazenar os dados recebidos em cache 104. O cache 104 pode compreender uma mídia de armazenamento legível por computador, como memória flash, um disco rígido, RAM, ou qualquer outra mídia de armazenamento adequada.
[0081] O servidor de proxy 102 pode agir como um servidor proxy para o cliente DASH 110. Por exemplo, o servidor de proxy 102 pode fornecer um arquivo MPD ou outro arquivo de manifesto para o cliente DASH 110. O servidor de proxy 102 pode anunciar momentos de disponibilidade para segmentos no arquivo de MPD, bem como hiperlinks a partir dos quais os segmentos podem ser recuperados. Estas hiperlinks podem incluir um prefixo de endereço de hospedeiro local correspondente ao dispositivo cliente 40 (por exemplo, 127.0.0.1 para IPv4). Desta forma, o cliente DASH 110 pode solicitar segmentos do servidor de proxy 102 utilizando solicitações GET HTTP ou solicitações GET parciais. Por exemplo, para um segmento disponível a partir do link http://127.0.0.1/repl/seg3, o cliente DASH 110 pode construir uma solicitação GET HTTP que inclui um pedido para http://127.0.0.1/repl/seg3, e submeter o pedido ao servidor de proxy 102. O servidor de proxy 102 pode recuperar os dados solicitados do cache 104 e fornecer os dados ao cliente DASH 110 em resposta a esses pedidos.
[0082] Depois de receber um segmento, o cliente DASH 110 poderá passar os dados do segmento para o aplicativo de mídia 112, se o segmento for total ou parcialmente recebido. O cliente DASH 110 pode processar o segmento, por exemplo, para extrair dados de mídia do segmento e/ou descartar dados que não são utilizáveis pelo aplicativo de mídia 112.
[0083] De acordo com as técnicas desta revelação, como explicado em maior detalhe abaixo, a unidade de middleware eMBMS 100 pode receber um ou mais grupos de anúncio e fornecer dados para um dos grupos de anúncio para o cliente DASH 110. Por exemplo, o cliente DASH 110 pode identificar um dos grupos de anúncio ou pode fornecer dados para um usuário para a unidade de middleware eMBMS 100 de modo que a unidade de middleware eMBMS 100 pode selecionar um dos grupos de anúncio.
[0084] A FIG. 3 é um diagrama conceitual ilustrando elementos do conteúdo multimídia exemplar 120. O conteúdo multimídia 120 pode corresponder aos conteúdos multimídia 64 (FIG. 1), ou outro conteúdo multimídia armazenado na mídia 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) 124 e uma pluralidade de representações 130-140. A representação 130 inclui dados de cabeçalho opcionais 132 e segmentos 134A-134N (segmentos 134), enquanto a representação 140 inclui dados de cabeçalho opcionais 142 e segmentos 144A-144N (segmentos 144). A letra N é utilizada para designar o último fragmento de filme em cada uma das representações 130, 140, por uma questão de conveniência. Em alguns exemplos, pode haver um número diferente de fragmentos de filme entre as representações 130, 140.
[0085] A MPD 124 pode compreender uma estrutura de dados separada das representações 130-140. A MPD 124 pode corresponder ao arquivo de manifesto 66 da FIG. 1. Da mesma forma, as representações 130-140 podem corresponder às representações 68 da FIG. 1. Em geral, a MPD 124 pode incluir dados que geralmente descrevem características de representações 130-140, como características de codificação e renderização, conjuntos de adaptação, um perfil ao qual a MPD 124 corresponde, informações de tipo texto, informação de ângulo da câmera, informações de classificação, informações de modo de truque (por exemplo, informações indicativas das representações que incluem subsequências temporais), e/ou informações para recuperar períodos remotos (por exemplo, para a inserção de anúncio direcionada para conteúdo de mídia durante a reprodução).
[0086] Os dados do cabeçalho 132, quando presentes, podem descrever as características de segmentos 134, por exemplo, locais temporais de pontos de acesso aleatórios (RAPs, também conhecidos como pontos de acesso do fluxo (SAPs)), quais dos segmentos 134 inclui pontos de acesso aleatório, deslocamentos de byte para os pontos de acesso aleatório dentro dos segmentos 134, localizadores de recursos uniformes (URL) dos segmentos 134, ou outros aspectos de segmentos 134. Os dados de cabeçalho 142, quando presentes, podem descrever características semelhantes para os segmentos 144. Adicionalmente ou alternativamente, essas características podem ser totalmente incluídas dentro da MPD 124.
[0087] Os segmentos 134, 144 incluem uma ou mais amostras de vídeo codificadas, cada uma das quais podem incluir quadros ou fatias de dados de vídeo. Cada uma das amostras de vídeo codificadas dos segmentos 134 pode ter características semelhantes, por exemplo, requisitos de altura, largura e de largura de banda. Essas características podem ser descritas pelos dados da MPD 124, embora tais dados não sejam ilustrados no exemplo da FIG. 3. A MPD 124 pode incluir as características como descrito pela especificação do 3GPP, com a adição de qualquer ou toda a informação sinalizada descrita na presente revelação.
[0088] Cada um dos segmentos 134, 144 pode ser associado a um localizador de recursos uniforme único (URL). Assim, cada um dos segmentos 134, 144 pode ser, independentemente recuperável utilizando um protocolo de rede de streaming, como DASH. Desta maneira, um dispositivo de destino, como o dispositivo cliente 40, pode utilizar um pedido GET HTTP para recuperar segmentos 134 ou 124. Em alguns exemplos, o dispositivo cliente 40 pode usar solicitações GET HTTP parciais para recuperar intervalos de bytes específicos dos segmentos 134 ou 124.
[0089] A FIG. 4 é um diagrama de blocos que ilustra outro sistema exemplar 150 que pode implementar as técnicas desta revelação. Os elementos do sistema 150 na FIG. 4 podem geralmente corresponder aos elementos da FIG. 1. Por exemplo, o sistema 150 inclui servidor de decisão de anúncio (ad) 154, sistema de distribuição de conteúdo 180 e dispositivo cliente 152. Os elementos do sistema de distribuição de conteúdo 180 podem geralmente corresponder ao dispositivo de preparação de conteúdo 20 e/ou ao dispositivo servidor 60 da FIG. 1, enquanto que os elementos do dispositivo cliente 152 podem corresponder a um dispositivo cliente 40 da FIG. 1. Em alguns exemplos, os elementos do dispositivo cliente 152 podem corresponder à unidade de recuperação 52 da FIG. 1.
[0090] Neste exemplo, o sistema de distribuição de conteúdo 180 inclui gerador de MPD 156, embalador 158, e servidor de origem 160. O gerador de MPD 156 gera uma MPD 162 para o conteúdo principal de mídia (por exemplo, dados de mídia para um programa que um usuário deseja assistir), bem como uma ou mais MPDs para anúncios, como MPD 164. A MPD 162 descreve o conteúdo de mídia 166A-166C, enquanto a MPD 164 descreve dados do anúncio 168A-168C. O empacotador 158 reúne conteúdo de mídia 166A-166C e dados do anúncio 168A- 168C. O encomendador 158 pode geralmente corresponder à unidade de encapsulamento 30 (FIG. 1).
[0091] O dispositivo cliente 152 inclui aplicativo de mídia 170, que inclui o serviço de gerenciamento de anúncio 172. O dispositivo cliente 152 também inclui o cliente DASH 176 para a recuperação de conteúdo de mídia principal e o cliente DASH 174 para recuperar dados de anúncio. O aplicativo 170 recupera URLs da MPD do servidor de decisão de ad 154 através do serviço de gerenciamento de anúncio 172 e fornece as URLs da MPD para o cliente DASH 176 e cliente DASH 174. Um ou outro um ambos o cliente DASH 174 e cliente DASH 176 podem corresponder ao cliente DASH 110 da FIG. 2. O serviço de gerenciamento de anúncio 172 pode selecionar a MPD(s) para anúncios de acordo com as técnicas da presente revelação, como discutido em maior detalhe abaixo. O cliente DASH 174 pode usar a MPD(s) para anúncios para recuperar dados de publicidade (por exemplo, um ou mais dados de anúncio 168A- 168C) do servidor de origem 160. O cliente DASH 176 pode recuperar o conteúdo principal (por exemplo, um ou mais de conteúdo principal 166A-166C) do servidor de origem 160.
[0092] De acordo com o primeiro exemplo de técnica desta divulgação, eventos específicos de aplicativo podem ser passados para o aplicativo 170, que interage com o servidor de decisão de ad externo 154 para fornecer ao cliente DASH 174 uma URL da MPD que aponta para o conteúdo do anúncio, por exemplo, dados do anúncio 168A-168C. O aplicativo 170 pausa o programa principal, enquanto o conteúdo do anúncio é adquirido e reproduzido. Após a inserção do anúncio, o aplicativo 170 retoma a reprodução do programa principal.
[0093] O serviço de gerenciamento de anúncio 172 pode empregar a informação de perfil/preferência do usuário (“UP/P”), histórico de consumo de conteúdo, um mecanismo de recomendação de anúncio, etc. (isoladamente ou em qualquer combinação), para suportar a inserção de anúncios direcionados. Tecnologias de rede gerais podem ser usadas para este fim. Adicional ou alternativamente, outros métodos, como VMAP (Lista de Reprodução com Vários Anúncios de Vídeo) definido pelo IAB (Departamento de Publicidade Interativa) podem ser usados.
[0094] Neste exemplo, uma camada de serviço MBMS (não mostrada) fornece uma função de entrega estritamente para clientes DASH 174, 176. Por exemplo, a camada de serviço MBMS pode entregar e disponibilizar dados de conteúdo disponíveis de anúncios designados para grupos de usuário alvo ou perfis, onde cada categoria pode ser mapeada para uma URL única. O cliente MBMS pode baixar e armazenar em cache todos os anúncios de broadcast para pedido seletivo pelo cliente DASH 176 em nome do aplicativo 170.
[0095] O aplicativo 170, os clientes DASH 174, 176, gerador de MPD 156, e empacotador 158 podem ser implementados em hardware ou software. Quando implementados em software, presume-se que o hardware requerido, como uma ou mais unidades de processamento e um ou mais mídias de armazenamento legíveis por computador, também são fornecidas. A mídia de armazenamento legível por computador pode armazenar instruções para o software, e as unidades de processamento podem executar as instruções para executar a funcionalidade descrita acima.
[0096] A FIG. 5 é um diagrama de blocos que ilustra outro sistema exemplar 200 que pode implementar as técnicas desta revelação. Os elementos do sistema 200 na FIG. 5 podem geralmente corresponder aos elementos da FIG. 1. Por exemplo, o sistema 200 inclui servidor de decisão de anúncio (ad) 208, sistema de distribuição de conteúdo 212 e dispositivo cliente 206. Os elementos do sistema de distribuição de conteúdo 212 podem geralmente corresponder ao dispositivo de preparação de conteúdo 20 e/ou ao dispositivo servidor 60 da FIG. 1, enquanto que os elementos do dispositivo cliente 206 podem corresponder a um dispositivo cliente 40 da FIG. 1. Em alguns exemplos, os elementos do dispositivo cliente 206 podem corresponder à unidade de recuperação 52 da FIG. 1.
[0097] Neste exemplo, o dispositivo cliente 206 inclui mecanismo de mídia 202 e cliente de acesso DASH 204. O cliente de acesso DASH 204 pode corresponder ao cliente DASH 110 da FIG. 2, enquanto o mecanismo de mídia 202 pode corresponder ao aplicativo de mídia 112 da Fig. 2. O sistema de distribuição de conteúdo 212 inclui gerador de MPD 214, empacotador 216, e rede de distribuição de conteúdo (CDN)/servidor de origem 218. O servidor de origem 218 armazena a MPD 220, o conteúdo principal 222A-222C, e dados do anúncio 224A-224C.
[0098] O exemplo da FIG. 5 representa uma implementação possível do segundo exemplo de um conjunto de técnicas desta revelação. Neste segundo conjunto exemplar de técnicas, o conceito básico é que o cliente de acesso DASH 204 e a pilha HTTP são “responsáveis” para a aquisição de anúncios apropriados. Um Período Remoto descrito na MPD 220 pode referenciar o conteúdo do anúncio (por exemplo, dados do anúncio 224A-224C), que podem ser direcionados para um grupo/perfil de usuário específico, pela formatação adequada do Period@xlink:href. Assim, quando o cliente de acesso DASH 204 direciona um XLink (isto é, dados de Linguagem de Ligação XML) para o resolvedor XLink 210, o resolvedor XLink 210 recupera dados descrevendo um Período remoto apropriado a partir do servidor de decisão de ad 208. O CDN/servidor de origem 218 pode enviar a MPD 220, contendo o período remoto, com antecedência se tempo de intervalo de anúncio é conhecido no momento em que o gerador de MPD 214 gera a MPD 220. Alternativamente, o CDN/servidor de origem 218 pode enviar os dados de período remoto dinamicamente usando um evento específico de DASH para acionar o cliente de acesso DASH 204 para adquirir atualizações para MPD 220.
[0099] As técnicas para seleção de anúncios podem ser semelhantes às descritas acima em relação à FIG. 4. Por exemplo, a informação UP/P, histórico de consumo de conteúdo, um mecanismo de recomendação anúncio, ou semelhantes podem ser empregados para suportar a inserção de anúncio direcionada.
[0100] Como mencionado acima, o segundo exemplo inclui um conjunto de técnicas. Ou seja, várias opções (utilizadas isoladamente ou em qualquer combinação) são possíveis. Na primeira opção, a camada de serviço MBMS (não mostrada) executa a recepção de anúncio publicitário não seletiva. A camada de serviço MBMS pode entregar e disponibilizar conteúdo de anúncio disponíveis designado para grupos de usuário alvo ou perfis, onde cada categoria pode ser mapeada para uma URL única. O cliente MBMS pode baixar e armazenar em cache todos os anúncios de broadcast para pedido seletivo pelo cliente de acesso DASH 204 e/ou mecanismo de mídia 202.
[0101] Na segunda opção, a camada de serviço MBMS executa a recepção de anúncio publicitário seletiva. Um Centro de Serviço de Multicast Broadcast (BM-SC) pode anexar metadados a cado anúncio (por exemplo, dados do anúncio 224A-224C) e o cliente de acesso DASH 204 pode informar o cliente MBMS de uma categoria preferida de dados do anúncio para fazer download e armazenar em cache seletivamente, de modo que o cliente MBMS seletivamente downloads e armazena em cache os anúncios de transmissão (por exemplo, um dos dados do anúncio 224A-224C).
[0102] O mecanismo de mídia 202, o cliente de acesso DASH 204, gerador de MPD 214, e empacotador 216 podem ser implementados em hardware ou software. Quando implementados em software, presume-se que o hardware requerido, como uma ou mais unidades de processamento e um ou mais mídias de armazenamento legíveis por computador, também são fornecidas. A mídia de armazenamento legível por computador pode armazenar instruções para o software, e as unidades de processamento podem executar as instruções para executar a funcionalidade descrita acima.
[0103] As FIGs. 6A-6B são diagramas de sequência ilustrando vários métodos exemplares nos quais um cliente DASH (ex., cliente de acesso DASH 204) garante a recepção de conteúdo de anúncio adequado. Os vários métodos das Figs. 6A-8B são consistentes com o segundo exemplo de um conjunto de técnicas desta revelação, descritas acima em relação à FIG. 5.
[0104] Nas FIGs. 6A-8B, vários elementos são descritos como realizando várias tarefas. Estes elementos incluem um aplicativo (ex., mecanismo de mídia 202), um cliente DASH (ex., cliente de acesso DASH 204), um cliente MBMS (que pode incluir um proxy de HTTP local e resolvedor de XLink 210), um BM-SC (ex., CDN/servidor de origem 218), um servidor de decisão de ad (ex., servidor de decisão de ad 208), um provedor de conteúdo (ex., incluindo gerador de MPD 214 e empacotador 216) e um provedor (não mostrado na FIG. 5).
[0105] As FIGs. 6A e 6B ilustram um exemplo de um método de acordo com a primeira opção descrita acima para o segundo conjunto exemplar das técnicas desta revelação. Ainda, o exemplo das FIGs. 6A e 6B corresponde a um estado no qual um tempo de início de anúncio publicitário é desconhecido quando a MPD é gerada (por exemplo, para um evento ao vivo). As FIGs. 6A e 6B ilustram ações executadas por vários elementos, incluindo um aplicativo (por exemplo, aplicativo de mídia 112 da FIG. 2), um cliente DASH (por exemplo, cliente DASH 110 da FIG. 2), um cliente MBMS (por exemplo, unidade de middleware eMBMS 100 da FIG. 2), um BM-SC, um servidor de decisão de ad, um provedor de conteúdo, e um provedor de ad.
[0106] No exemplo das FIGs. 6A e 6B, assume-se que o cliente DASH está ciente de que um groupID local é igual a “B”. Também assume-se como sendo um acordo comercial entre a operadora MBMS, o provedor de conteúdo, e o provedor do ad no fornecimento de conteúdo/ad e formato de MPD. Inicialmente, no exemplo das FIGs. 6A e 6B, o BM-SC entrega uma USD com um fragmento de MPD para o cliente MBMS, que encaminha a MPD para o cliente DASH. O BM-SC pode então entregar, via broadcast, três arquivos correspondentes aos elementos de Período remoto com BaseURLs de, por exemplo, 1) http://adserver.com/adl?id=”A”, 2) http://adserver.com/adl?id=”B”, e 3) http://adserver.com/adl?id="C ", cada um com momento do início do Período no tempo futuro T1. O cliente MBMS faz o download e armazena em cache todos os elementos do Período remoto.
[0107] Em algum momento no futuro, como resultado do recebimento de uma mensagem sugestão do provedor de ad, indicando uma ocorrência de inserção de ad iminente, o BM-SC sinaliza um evento específico DASH (por exemplo, através de um evento MPD ou uma mensagem de evento dentro da banda) para acionar a aquisição de uma MPD atualizada, a qual o cliente MBMS recebe e encaminha para o cliente DASH. O BM-SC, em seguida, transmite a MPD atualizada, USBD, e fragmentos de Programação, onde o USBD contém deliveryMethod que referencia sessão(ões) FLUTE que transportam conteúdo de ad em períodos remotos, e a Programação declara uma futura transmissão de ad. Em resposta, o cliente DASH busca uma MPD atualizada (onde a MPD indica um período remoto com Period@xlink:href =http://adserver.com/adl?id=$groupID$ and @xlink: actuate = “onRequest,” neste exemplo. Neste caso, o cliente DASH não tenta dereferenciar o link para o Período remoto imediatamente, mas adia essa ação de dereferenciamento até esperar o momento da reprodução do conteúdo entre nesse período.
[0108] O BM-SC, em seguida, transmite os arquivos de conteúdo de ad referenciados pelos elementos do Período remoto, com cado anúncio marcado por um groupID alvo (por exemplo, como um atributo de extensão de elemento dp ‘Arquivo’ “$groupID$” da tabela de entrega de arquivo (FDT), por exemplo, como discutido em relação às FIGs. 13A e 13B abaixo). Adicional ou alternativamente, como discutido abaixo, um groupIDFilter de um fragmento de Descrição de Filtro pode identificar os dados do anúncio. O cliente MBMS faz o download e armazena em cache todos os anúncios, neste exemplo. Na medida em que o momento T1 se aproxima, o cliente DASH solicita o dereferenciamente de elementos de Período remoto através da emissão de uma solicitação HTTP para a URL que aparece em @xlink:href e fornece ao cliente MBMS um valor de groupID local de “B”. Em resposta o cliente MBMS registra o groupID = “B” para o fornecimento de ad adequado mediante pedido e entrega o Período associado com BaseURL = “http://adserver.com/adl?id=”B” para o cliente DASH. O cliente DASH, em seguida, fornece segmentos deste anúncio para o aplicativo. Este processo continua até que os dados do anúncio tenham sido totalmente reproduzidos, e depois o broadcast normal do conteúdo principal poderá continuar.
[0109] As FIGs. 7A e 7B ilustram um exemplo no qual um tempo de disponibilidade do anúncio (concessão do ad) é desconhecido no momento quando a MPD é gerada (por exemplo, para um evento ao vivo). O exemplo das FIGs. 7A e 7B corresponde a opção de dois, como descrito acima, onde há recebimento do anúncio seletivo pelo cliente MBMS. Neste exemplo, a entrega do anúncio por broadcast ocorre apenas antes do tempo de concessão do ad. As FIGs. 7A e 7B ilustram ações executadas por vários elementos, incluindo um aplicativo (por exemplo, aplicativo de mídia 112 da FIG. 2), um cliente DASH (por exemplo, cliente DASH 110 da FIG. 2), um cliente MBMS (por exemplo, unidade de middleware eMBMS 100 da FIG. 2), um BM-SC, um servidor de decisão de ad, um provedor de conteúdo, e um provedor de ad.
[0110] No exemplo das FIGs. 7A e 7B, assume-se que a informação de estado (como cookies, informação de assinatura, histórico de uso e similares) reside no equipamento de usuário (UE) e está disponível para os dispositivos de rede por um cliente DASH em uma solicitação de HTTP. De modo similar, neste exemplo, assume-se que há um acordo comercial entre a operadora do MBBMS, o provedor de conteúdo e o provedor de ad em relação ao fornecimento de conteúdo/ad e formato do MPD.
[0111] Inicialmente, o BM-SC entrega uma USD com fragmento de MPD para o cliente MBMS, e o cliente MBMC encaminha a MPD para o cliente DASH. O BM-SC pode então entregar, via broadcast, três arquivos correspondentes aos elementos de Período remoto com BaseURLs de, por exemplo, 1) http://adserver.com/ad1?id= “A", 2) http://adserver.com/adl?id=”B”, and 3) http://adserver.com/adl ?id=”C,” cada com momento do início do Período no tempo futuro T1 . O cliente MBMS faz o download e armazena em cache todos os elementos do Período remoto. Em algum momento no futuro, como resultado do recebimento de uma mensagem sugestão do provedor de ad, indicando uma ocorrência de inserção de ad iminente, o BM- SC sinaliza um evento específico DASH (por exemplo, através de um evento MPD ou uma mensagem de evento dentro da banda) para acionar a aquisição de uma MPD atualizada, a qual o cliente MBMS recebe e encaminha para o cliente DASH. O BM- SC, em seguida, transmite a MPD atualizada, USBD, e fragmentos de Programação, onde o USBD contém deliveryMethod que referencia sessão(ões) FLUTE que transportam conteúdo de ad em períodos remotos, e a Programação declara uma futura transmissão de ad.
[0112] Em resposta, o cliente DASH busca uma MPD atualizada (onde a MPD indica um período remoto com Period@xlink:href =http://adserver.com/adl?id=$groupID$ e @xlink:actuate = "onLoad". Neste caso, o cliente DASH vai eliminar a referência do link para o Período remoto imediatamente após o carregamento da MPD, e vai passar as informações de estado do UE descritas acima para o cliente MBMS que atua como a Resolvedor de Xlink. O cliente MBMS em seguida, mapeia as informações de estado de um dos grupos de anúncio para posterior download do anúncio direcionado. Neste exemplo, assume-se que o cliente MBMS mapeia a informação de estado para groupID = “B.”
[0113] O cliente DASH, em seguida, solicita o dereferenciamento do elemento de Período remoto através da emissão de um GET de HTTP para a URL que aparece no @xlink:href. O cliente MBMS responde pela entrega do elemento de período associado com BaseURL = “http://adserver.com/adl?id=”B”” neste exemplo. O BM-SC, em seguida, transmite os arquivos de conteúdo de anúncio referenciados pelos elementos do Período remoto, com cado anúncio marcado pelo groupID alvo (por exemplo, como um atributo de extensão FDT, como discutido em relação às FIGs. 13A e 13B abaixo). Adicional ou alternativamente, como discutido abaixo, um groupIDFilter de um fragmento de Descrição de Filtro pode identificar os dados do anúncio.
[0114] O MBMS pode, então, seletivamente fazer o download e armazenar em cache ads com groupID = “B” neste exemplo. Na medida em que o momento T1 se aproxima, o cliente DASH solicita o dereferenciamente de elementos de Período remoto através da emissão de uma solicitação HTTP para a URL que aparece em @xlink:href e fornece ao cliente MBMS um valor de groupID local de “B”. Em resposta o cliente MBMS registra o groupID = “B” para o fornecimento de ad adequado mediante pedido e entrega o Período associado com BaseURL = “http://adserver.com/adl?id=”B” para o cliente DASH. O cliente DASH, em seguida, fornece segmentos deste anúncio para o aplicativo. Este processo continua até que os dados do anúncio tenham sido totalmente reproduzidos, e depois o broadcast normal do conteúdo principal poderá continuar.
[0115] As FIGs. 8A e 8B ilustram um exemplo no qual um tempo de disponibilidade do anúncio (concessão do ad) é desconhecido no momento quando a MPD é gerada (por exemplo, para um evento ao vivo). O exemplo das FIGs. 7A e 7B corresponde a opção de dois, como descrito acima, onde o ad é transmitido por broadcast antes de haver recebimento do anúncio seletivo pelo cliente MBMS. Neste exemplo das FIGs. 8A e 8B, a entrega de anúncio por broadcast ocorre bem antes do tempo de concessão do ad, e é seletivamente armazenado em cache até seu momento para reproduzir a anúncio. As FIGs. 8A e 8B ilustram ações executadas por vários elementos, incluindo um aplicativo (por exemplo, aplicativo de mídia 112 da FIG. 2), um cliente DASH (por exemplo, cliente DASH 110 da FIG. 2), um cliente MBMS (por exemplo, unidade de middleware eMBMS 100 da FIG. 2), um BM- SC, um servidor de decisão de ad, um provedor de conteúdo, e um provedor de ad.
[0116] No exemplo das FIGs. 8A e 8B, assume-se que a informação de estado (como cookies, informação de assinatura, histórico de uso e similares) reside no equipamento de usuário (UE). Ao contrário do exemplo das FIGs. 7A e 7B, o cliente DASH passa a informação de estado para o cliente MBMS durante o pedido de HTTP inicial para o conteúdo DASH. Similar ao exemplo das FIGs. 7A e 7B, assume-se que há um acordo comercial entre a operadora do MBBMS, o provedor de conteúdo e o provedor de ad em relação ao fornecimento de conteúdo/ad e formato do MPD.
[0117] Portanto, neste exemplo, o cliente MBMS pode mapear as informações de estado para o dispositivo cliente (UE) e para um groupID, por exemplo, groupID = “B”, logo no início, para posterior download do anúncio direcionado. O BM-SC pode então transmitir os arquivos do conteúdo de anúncio de acordo com a Programação entregue nos fragmentos USD, o que pode ocorrer bem antes de uma concessão inicial do anúncio tornar-se possível. Os conteúdos de anúncio são referenciados pelos elementos do Período remoto, com cada anúncio marcado por um groupID alvo (por exemplo, como atributo de extensão FDT, como discutido em relação às FIGs. 13A e 13B abaixo). Adicional ou alternativamente, como discutido abaixo, um groupIDFilter de um fragmento de Descrição de Filtro pode identificar os dados do anúncio. O cliente MBMS pode, então, seletivamente fazer o download e armazenar em cache ads com groupID = “B” neste exemplo.
[0118] Depois, o BM-SC entrega uma USD com fragmento de MPD para o cliente MBMS, e o cliente MBMC encaminha a MPD para o cliente DASH. O BM-SC pode então entregar, via broadcast, três arquivos correspondentes aos elementos de Período remoto com BaseURLs de, por exemplo, 1) http://adserver.com/ad1?id= “A”, 2) http://adserver.com/ad1?id= “B”, e 3) http://adserver.com/adl?id=”C,”, cada com um tempo de início de período o tempo futuro T1. Porque o cliente MBMS já determinou o valor de groupID associado ao usuário (neste exemplo, groupID = “B”), ele pode fazer o download e armazenar em cache o elemento do Período remoto associado com a BaseURL http://adserver.com/adl?id= “B”. Em algum momento no futuro, como resultado do recebimento de uma mensagem sugestão do provedor de ad, indicando uma ocorrência de inserção de ad iminente, o BM-SC sinaliza um evento específico DASH (por exemplo, através de um evento MPD ou uma mensagem de evento dentro da banda) para acionar a aquisição de uma MPD atualizada, a qual o cliente MBMS recebe e encaminha para o cliente DASH. O BM-SC, em seguida, transmite um fragmento MPD atualizado, que o cliente MBMS recebe.
[0119] O cliente DASH busca então uma MPD atualizada (onde a MPD indica um período remoto com Period@xlink:href = http://adserver.com/adl?id=B e @xlink: acionar = "onLoad". Neste caso, o cliente DASH cancelará a referência ao link para o Período remoto. Do mesmo modo, no presente exemplo, o cliente DASH não necessita substituir um valor para um parâmetro na URL do XLink, porque o próprio MPD especifica um valor para o grupo de anúncio (B, neste exemplo). O cliente MBMS responde pela entrega do elemento de período associado com BaseURL = "http://adserver.com/adl?id="B" neste exemplo. Isto é, o cliente MBMS só irá terá armazenado em cache os dados associados com o grupo de anúncio “B”, neste exemplo, como discutido acima.
[0120] Na medida em que o tempo T1 se aproxima, o cliente DASH solicita e recebe do cliente MBMS, o primeiro segmento do conteúdo, isto é, o anúncio direcionado, associado com o elemento de Período recebido anteriormente. O cliente DASH, em seguida, fornece o conteúdo de mídia deste segmento do anúncio para o aplicativo. Este processo continua até que os dados do anúncio tenham sido totalmente reproduzidos, e depois o broadcast normal do conteúdo principal poderá continuar.
[0121] As FIGs. 6A-8B representam apenas alguns dos possíveis exemplos de acordo com as técnicas desta revelação. Outras variações de fluxo de chamada para o método baseado em servidor também são possíveis. Por exemplo, no caso de fornecimento de anúncios por broadcast que ocorre bem antes do concessão do anúncio, o valor do Periodo@xlink:actuate realizado na atualização da MPD poderia ser definido como “onRequest” (em vez de “onLoad”). Porque o anúncio(s) direcionado já foram baixados e armazenados em cache no UE seletivamente, não há tempo de urgência para resolver o xlink, contanto que isso ocorra antes do concessão do anúncio. Se por algum motivo, os anúncios não direcionados estão disponíveis no dispositivo após a ocorrência da concessão do anúncio, um anúncio padrão pré-armazenado poderia ser reproduzido em seu lugar.
[0122] Há também diferentes mecanismos possíveis pelos quais o cliente MBMS deriva o valor adequado de “groupID” da informação de estado de UE fornecida pelo cliente DASH. Como exemplo, pode haver acesso aos facilitadores residentes no UE, como um banco de dados de UP/P local, mecanismo de recomendação de conteúdo, ou realizar a inferência usando log do histórico de uso armazenado localmente. Como outro exemplo, pode haver acesso aos facilitadores do lado da rede, como um banco de dados UP/P externo ou mecanismo de recomendação de conteúdo.
[0123] O terceiro exemplo das técnicas da presente revelação, que é direcionado à seleção de anúncio assistida pelo cliente MBMS, é descrito com referência às FIGs. 9 a 11B. O conceito básico do terceiro exemplo é que o cliente MBMS seletivamente downloads e armazena em cache anúncios transmitidos com base em metadados de anúncios e/ou regras de filtragem contidas em USD. O fragmento de Descrição de Filtro pode ser estendido para transportar dados de filtragem de anúncios. Este exemplo pressupõe a disponibilidade de facilitadores, como informações UP/P, histórico de consumo de conteúdo, etc, para o cliente MBMS. Por exemplo, os facilitadores podem incluir a informação UP/P residente no dispositivo que é acessível ao cliente MBMS. Dados de UP/P específicos e interações não estão descritos, mas podem ser determinados por aqueles versados na técnica.
[0124] Além disso, a camada de serviço MBMS fornece uma função de filtragem/seleção de anúncio. Assume- se que os anúncios de broadcast são entregues antes do programa (por exemplo, Apresentação de Mídia DASH) para download e armazenamento em cache seletivo pelo cliente MBMS. O mecanismo de seleção de anúncios pelo cliente MBMS pode ser específico da implementação.
[0125] A FIG. 9 é um diagrama conceitual que ilustra um fragmento de Descrição de Filtro exemplar, como definido atualmente, para carregar os dados do filtro de localização. A FIG. 10 é um diagrama conceitual que ilustra extensões para o fragmento de Descrição do Filtro para carregar os dados de Preferência & Perfil do Usuário (UP/P). No exemplo da FIG. 10, o elemento userPrefProfData contém pares de atributo-valor (ex., demográficos de usuário, categoria do conteúdo, classificação, popularidade, etc.) para seleção do anúncio. O elemento userPrefProfRule contém uma regra de filtragem (condições e lógica específicas) para seleção de anúncio.
[0126] As FIGs. 11A e 11B são diagramas de sequência que ilustram um exemplo de método para seleção de anúncio auxiliada por cliente MBMS de acordo com as técnicas desta revelação. Neste exemplo, um tempo de início do intervalo do anúncio é conhecido no momento em que a MPD é gerada. As unidades ativas das FIGs. 11A e 11B são substancialmente similares àquelas das FIGs. 6A a 8B. As FIGs. 11 A e 11B ilustram ações executadas por vários elementos, incluindo um aplicativo (por exemplo, aplicativo de mídia 112 da FIG. 2), um cliente DASH (por exemplo, cliente DASH 110 da FIG. 2), um cliente MBMS (por exemplo, unidade de middleware eMBMS 100 da FIG. 2), um BM-SC, um servidor de decisão de ad, um provedor de conteúdo, e um provedor de ad.
[0127] Assume-se que no exemplo das FIGs. 11A e 11B, que o cliente MBMS acessou os dados UP/P, e que há um acordo comercial entre a operadora MBMS, o provedor de conteúdo, e o provedor de anúncio em relação ao fornecimento do anúncio e formato de MPD. Inicialmente, o BM-SC fornece um USD, que inclui uma MPD e uma Descrição de Filtro, por exemplo, de acordo com o exemplo da FIG. 10. O aplicativo envia uma URL de MPD para o cliente DASH, que, em seguida, busca a MPD da URL. Assume-se que a MPD inclui Period_1 para conteúdo regular, Period_2 remoto com um XLink para o conteúdo do anúncio, com atributo xlink:actuate = "onRequest", e Period_3 com conteúdo mais regular. Isto é, neste exemplo, o Period_2 representa um intervalo do anúncio publicitário predeterminado. O provedor de conteúdo fornece o conteúdo regular (ou principal) para o BM-SC, e o provedor de anúncios fornece o conteúdo de anúncio para o BM-SC.
[0128] O BM-SC transmite por broadcast os (correspondendo ao conteúdo referenciado pelo Xlink no Period_2) para o cliente MBMS. O cliente MBMS seletivamente downloads e armazena em cache os anúncios de acordo com, por exemplo, dados UP/P ou regras da Descrição de Filtro. O BM-SC, em seguida, transmite por broadcast segmentos do Period_1 para o cliente MBMS. Na medida em que o Period_2 se aproxima, o cliente DASH solicita o dereferenciamento do elemento de período remoto (correspondendo ao Period_2, neste exemplo) através da emissão de um pedido HTTP para a URL que aparece no @xlink:href. O cliente MBMS em seguida, entrega o elemento de Período (correspondente ao Period_2) referenciado pelo @xlink:href. O cliente DASH busca Segmentos do Period_1 (por exemplo, URL do Segmento como: “http://example.com/per-l/rep-512/seg-i.3gp”, onde i e {1,99}).
[0129] O cliente DASH então envia os segmentos do Período 1 (o conteúdo do programa) para o aplicativo. O cliente DASH também solicita o segmento do Period_2 (referenciado pelo xlink) a partir do cliente MBMS. O cliente MBMS redireciona o cliente DASH para um endereço de hospedeiro local usando, por exemplo, uma resposta de HTTP 303, para recuperar os segmentos do Period_2 a partir de um cache local. O cliente DASH então busca Segmentos do Period_2 para o conteúdo do anúncio em cache (por exemplo, URL do Segmento como: “http://localhost.com/per-2/rep- 512/seg- j.3gp”, onde j e {100,129}).
[0130] O cliente DASH então envia os segmentos do Period_2 (o conteúdo do anúncio) para o aplicativo. O BM-SC também transmite por broadcast segmentos do Period_3 para o cliente MBMS. O cliente DASH também solicita do Period_3 a partir do cliente MBMS (por exemplo, URL do Segmento como: “http://example.com/per-3/rep-512/seg- k.3gp”, onde k e {130,200}). O cliente DASH então envia os segmentos do Period_3 (o conteúdo do programa) para o aplicativo.
[0131] A FIG. 12 é um diagrama de sequência ilustrando um exemplo de método para a seleção de anúncio auxiliada por cliente MBMS e inserção para Protocolo de Transporte em Tempo Real (RTP), de acordo com as técnicas desta revelação. Neste exemplo, um perfil de usuário é conhecido para o cliente MBMS. Quando os anúncios são enviados, o FDT pode incluir metadados para anúncios. Com base no perfil do usuário e Descrição do Filtro, o cliente MBMS pode baixar seletivamente e armazenar em cache os anúncios. Opcionalmente, o dispositivo cliente (UE) pode decidir se deseja inserir anúncios se estiver dentro da área local especificada por dados de perfil. A FIG. 12 ilustra ações executadas por vários elementos, incluindo um aplicativo (por exemplo, aplicativo de mídia 112 da FIG. 2), um cliente DASH (por exemplo, cliente DASH 110 da FIG. 2), um cliente MBMS (por exemplo, unidade de middleware eMBMS 100 da FIG. 2), um BM-SC, um servidor de decisão de ad, um provedor de conteúdo, e um provedor de ad.
[0132] Assume-se que no exemplo da FIG. 12, que o cliente MBMS acessou os dados UP/P, e que há um acordo comercial entre a operadora MBMS, o provedor de conteúdo, e o provedor de anúncio em relação ao fornecimento do anúncio. Inicialmente, o BM-SC fornece um USD, que inclui uma Descrição de Filtro, por exemplo, de acordo com o exemplo da FIG. 10. O aplicativo envia uma URL para o cliente DASH, em seguida, executa a Configuração e Reprodução, de acordo com o RTP. O provedor de conteúdo fornece o conteúdo regular (ou principal) para o BM-SC, e o provedor de anúncios fornece o conteúdo de anúncio para o BM-SC.
[0133] O BM-SC, em seguida, começa a transmissão de anúncios (com metadados). O cliente MBMS seletivamente downloads e armazena em cache os anúncios de acordo com UP/P ou regras da Descrição de Filtro. O BM-SC usa RTP para enviar dados de vídeo e áudio. O cliente MBMS, em seguida, determina se o dispositivo cliente (UE) está dentro de um local desejado para inserir anúncios por dados de perfil. Supondo-se que o dispositivo cliente está em tal local, o cliente MBMS insere anúncios por os metadados com pacotes de áudio e vídeo de RTP. O cliente MBMS em seguida, exclui os anúncios quando eles expiram, para os metadados.
[0134] As FIGs. 13A-13D são diagramas conceituais que ilustram uma extensão exemplar para um elemento de Arquivo da tabela de entrega de arquivo (FDT). Neste exemplo, o elemento de Arquivo é estendido para incluir um atributo de Grupo, o que pode corresponder a um valor de groupID como discutido acima. Em particular, o elemento de arquivo 250 foi estendido para incluir atributo de grupo 252, chamado “mbms2014:groupID” com tipo xs:string, neste exemplo.
[0135] Deve ser entendido que, em alguns exemplos, um dispositivo cliente pode ser configurado para realizar qualquer uma ou todas as técnicas do primeiro exemplo, do segundo exemplo e do terceiro exemplo descritos acima. Por exemplo, diferentes redes de distribuição de conteúdo podem suportar mecanismos diferentes para a inserção de publicidade direcionada, e um dispositivo cliente pode implementar as técnicas de qualquer ou todos os primeiro exemplo, segundo exemplo e/ou terceiro exemplo. Como outro exemplo, uma rede de distribuição de conteúdo pode suportar qualquer uma ou todas as técnicas do primeiro exemplo, segundo exemplo e/ou terceiro exemplo acima descritos. Além disso, as técnicas do primeiro exemplo, segundo exemplo, e/ou terceiro exemplo acima descritas pode ser realizadas em qualquer combinação.
[0136] O parâmetro de extensão FDT do “groupID” mostrado nas FIGs. 13A-13D é apenas um exemplo. Outras técnicas podem ser utilizadas de acordo com as técnicas desta revelação. Por exemplo, além de ou em alternativa ao uso de um parâmetro de extensão de FDT (“groupID”) como metadados para um arquivo de anúncio associado, para permitir que o cliente MBMS filtre apenas os anúncios especificamente adequados para o usuário, outra possibilidade é estender o USD existente. Por exemplo, um novo elemento “groupIDFilter” pode ser adicionado ao fragmento de Descrição de Filtro (onde o fragmento de Descrição de Filtro é referenciado por uma instância programada do arquivo no fragmento de Descrição da Programação; o cronograma de arquivo fornece a programação de transmissão para o arquivo do anúncio).
[0137] A FIG. 14 é um diagrama de blocos que ilustra outro sistema exemplar 300 que pode realizar as técnicas desta revelação. Os componentes do sistema 300 incluem entidades funcionais envolvidas no fornecimento, programação e entrega de conteúdo de mídia formatado por DASH e anúncios direcionados de um provedor de conteúdo e fonte de anúncio para o equipamento de usuário (UE) através do BM-SC. Neste exemplo, o sistema 300 inclui dispositivo cliente 302, provedor de conteúdo 314, servidor de decisão de ad 316, provedor de anúncio 318, e Centro de Serviço de Broadcast Multicast (BM-SC) 320. O dispositivo cliente 302 inclui mecanismo de mídia 304, cliente DASH 306 e cliente MBMS 308. O dispositivo cliente 302 representa um exemplo do UE. O cliente MBMS 308 inclui ainda o resolvedor de XLink 310 e cache de proxy HTTP 312. O BM-SC 320 inclui dados para USBD 322, MPD 324, conteúdo 326A - 326C (conteúdo 326), e anúncios (ads) 328A-328C (ads 328).
[0138] Em geral, o provedor de conteúdo 314 fornece conteúdo 326 para o BM-SC 320. O servidor de decisão de ad 316 sinaliza quando os anúncios devem ser inseridos (usando sugestões de inserção de anúncios) e fornece períodos remotos para os anúncios. O provedor de anúncio 318 fornece os anúncios 328 para o BM-SC 320. Os anúncios 328A-328C podem cada corresponder a diferentes grupos de usuários, a fim de direcionar anúncios para os usuários, como discutido acima.
[0139] O cliente MBMS 308 assina um grupo de broadcast ou de multicast, a fim de receber dados de uma ou mais dos conteúdos 326. Além disso, como explicado em maior detalhe abaixo em relação às FIGS. 15A e 15B, o cliente MBMS 308 pode receber seletivamente um dos anúncios 328A- 328C para ser inserido dentro de um intervalo de anúncio publicitário. O cliente MBMS 308 armazena o conteúdo e dados de anúncio no cache de proxy HTTP 312. Desta forma, o cliente DASH 306 pode recuperar dados de mídia (por exemplo, dados de conteúdo principais e dados de publicidade), enviando solicitações de HTTP para o cliente MBMS 308, que por sua vez envia dados e segmentos de MPD para o cliente 306. Para selecionar dados do anúncio apropriados, o cliente DASH 306 pode enviar um XLink para o cliente MBMS 308. O resolvedor de Xlink 310 pode resolver o Xlink, a fim de determinar os dados de publicidade a serem recebidos.
[0140] Na arquitetura exemplar da FIG. 14, a informação relacionada ao anúncio pode ser declarada usando MPD 324 e Segmentos de conteúdo 326, e as decisões de anúncios podem ser iniciadas por um pedido do cliente DASH 306 para a MPD e os recursos que ela descreve, ou seja, um elemento de Período remoto e Segmentos. Se o tempo de ocorrência do intervalo de anúncio é conhecido no momento da geração da MPD, a MPD contém o elemento de Período remoto que poderia ser enviado para o cliente DASH com bastante antecedência do intervalo do anúncio. Caso contrário, pode ser necessário contar com a funcionalidade de atualização de MPD, por exemplo, com base em atualizações de MPD síncronas com periodicidade definida pelo MPD@minimumUpdatePeriod, para sinalizar a oportunidade iminente para a inserção de anúncios direcionados. O cenário de funcionamento dos intervalos comerciais imprevisíveis será assumido na discussão a seguir.
[0141] Embora a interação nominal entre o cliente DASH 306 e o servidor de MPD (onde assume-se que este último reside no UE (ou seja, o dispositivo cliente 302), e cliente MBMS p/o 308, que inclui um proxy de HTTP local e cache 312) para a aquisição da MPD mais recente seja periódica, a ocorrência de intervalo de anúncios pode ser puramente assíncrona, por exemplo, ocorrendo durante um tempo por lesão em um jogo de futebol. Dependendo do tempo de configuração esperado do intervalo do anúncio - a partir do incidente que provoca o intervalo de anúncio até o momento de junção real da inserção de anúncios, o valor de MPD@minimumUpdatePeriod pode ser ajustado em conformidade de modo que tal evento dinâmico não vai ser desperdiçado pelo cliente DASH 306. A interação de HTTP para atualizações de MPD, provavelmente via GET condicional, pode ocorrer localmente dentro do UE para que nenhum tráfego de rede unicast seja constituído, e na maioria das vezes, o MPD previamente adquirido pelo cliente DASH 306 ainda é válido. Quando atualizado, o MPD pode carregar um indicador para um elemento de Período externo através do Period@xlink:href.
[0142] Como parte da interação de HTTP com o cliente MBMS 308, o cliente DASH 306 pode passar as informações de estado em relação ao UE/usuário local para o cliente MBMS 308. Exemplos de tais informações de estado incluem cookies, informações de assinatura e dados do histórico de consumo de conteúdo. As informações de estado podem ser fornecidas ao cliente MBMS 308 durante o pedido/resposta nominal para a MPD ou Segmentos de Mídia, ou durante o procedimento de resolução de XLink. O cliente MBMS 308 pode utilizar algum mecanismo, fora do escopo da TS 26.346 (por exemplo, acesso às informações de perfil/preferências do usuário local, histórico de consumo de conteúdo ou mecanismo de recomendação de conteúdo), para determinar um identificador de grupo ou perfil específico para o usuário. Tal “groupID” pode ser utilizado como um indicador do conteúdo de anúncio adequado ou preferencial para esse usuário. Quando os conteúdos do anúncio são transmitidos por broadcast (onde uma variedade de arquivos de anúncio é direcionada para diferentes usuários), o cliente MBMS usa o groupID como um filtro para baixar e armazenar em cache um ou mais anúncios específicos, a serem fornecidos ao cliente DASH mediante solicitação depois. A entrega por broadcast dos anúncios pode ocorrer com bastante antecedência ao intervalo do anúncio (por exemplo, durante a noite antes do jogo de futebol no dia seguinte), ou mais perto no tempo que precede o intervalo de anúncio real.
[0143] O download e armazenamento em cache seletivo dos anúncios pelo cliente MBMS 308 é possível, desde que ele tenha adquido as informações de estado local e mapeado os dados para o valor de groupID do usuário. Diferentes formas são possíveis para transmitir groupID como metadados para os anúncios associados para permitir a recepção de anúncios seletiva pelo cliente MBMS. Por exemplo, um groupID do atributo de extensão de FDT FLUTE pode ser especificado para o arquivo do anúncio identificado pelo TOI e Local do Conteúdo. Também é possível estender o fragmento de Descrição de Filtro existente pela adição de um novo elemento filho groupIDFilter sob o elemento FilterData, como identificador para o arquivo de anúncio correspondente cuja programação de entrega é anunciada por uma instância da programação do arquivo.
[0144] Na resolução do Xlink, o cliente MBMS 308 pode retornar a um elemento de Período remoto personalizado (ex., por groupID) para o usuário. Esse elemento de Período contém referências ao conteúdo do anúncio para a duração do período, incluindo informações de URL do segmento. O cliente DASH 306 pode então utilizar essa informação para buscar Segmentos para o conteúdo do anúncio nos momentos apropriados do intervalo de anúncio. Porque o conteúdo do anúncio correspondente já foi baixado e armazenado em cache pelo cliente MBMS 308 (em cache dentro do cache de proxy HTTP 312), ele pode ser devolvido ao cliente DASH 306 e por sua vez para o reprodutor de mídia/aplicativo (por exemplo, mecanismo de mídia 304) para renderização durante o intervalo de anúncios.
[0145] As FIGs. 15A e 15B são diagramas de sequência que ilustram um exemplo de método de acordo com as técnicas desta revelação. O método das FIGs. 15A e 15B podem ser realizado pelos componentes do sistema 300 da FIG. 14, embora outros sistemas também possam realizar esse método. Assume-se que há um acordo comercial entre a operadora do MBBMS, o provedor de conteúdo 314 e o provedor de ad 318 em relação ao fornecimento de conteúdo e anúncio e um formato da MPD 324. As FIGs. 15A e 15B ilustram ações executadas por vários elementos, incluindo um aplicativo (por exemplo, aplicativo de mídia 112 da FIG. 2 ou mecanismo de mídia 304 da FIG. 14), um cliente DASH (por exemplo, cliente DASH 110 da FIG. 2 ou cliente DASH 306 da FIG. 14), um cliente MBMS (por exemplo, unidade de middleware eMBMS 100 da FIG. 2 ou cliente MBMS 308 da FIG. 14), um BM-SC (ex., BM-SC 320 da FIG. 14), um servidor de decisão (por exemplo, servidor de decisão de anúncio 316 da FIG. 14), um provedor de conteúdo (por exemplo, provedor de conteúdo 314 da FIG. 14), e um provedor de ad (por exemplo, provedor de ad 318 da FIG. 14).
[0146] Inicialmente, o BM-SC 320 pode transmitir a entrega de um USD (incluindo um fragmento de MPD) para o cliente MBMS 308. Um aplicativo de mídia (por exemplo, mecanismo de mídia 304) pode solicitar enviar uma URL da MPD para o cliente DASH 306, que por sua vez pode adquirir a MPD (por exemplo, MPD 324) do cliente MBMS 308 (que pode armazenar em cache a MPD no cache de proxy HTTP 312). O cliente DASH 306 também pode passar as informações de estado para o cliente MBMS 308, o que pode indicar um conjunto de dados de anúncio (por exemplo, um grupo de publicidade) a ser obtido por um usuário do dispositivo cliente 302. O cliente DASH 306 pode pesquisar atualizações de MPD de acordo com MPD@minimumUpdatePeriod, o que pode ser sinalizado na MPD original. O cliente MBMS 308 pode, então, mapear a informação do estado para um identificador de grupo, por exemplo, groupID = “B”, neste exemplo, para o download subsequente do anúncio publicitário direcionado.
[0147] Para o conteúdo principal, pode haver entrega por broadcast normal e o consumo da Apresentação de Mídia DASH-sobre-MBMS. Posteriormente, o prestador de anúncios 318 pode fornecer um anúncio publicitário para o BM-SC 320. O BM-SC 320 pode transmitir os arquivos de conteúdo de anúncio acordo com uma Programação entregue em fragmentos de USD, como discutido acima. O conteúdo do anúncio (por exemplo, anúncios 328) pode ser referenciado pelos elementos de Período remota, com cado anúncio marcado por um groupID alvo. Com base no mapeamento discutido acima, o cliente MBMS 308 pode seletivamente fazer o download e armazenar em cache (no cache de proxy HTTP 312) anúncios marcados com groupID = “B”.
[0148] O servidor de decisão de anúncio 316 pode fornecer, ao BM-SC 320, três arquivos correspondentes aos elementos de Período remoto com BaseURLs de 1) http://adserver.com/adl?id=”A”, 2) http://adserver.com/adl?id=”B” e 3) http://adserver.com/adl?id=”C”, cada um com início do Período no tempo futuro T1. O BM-SC 320 pode então transmitir esses três arquivos de elementos de Período remoto. O cliente MBMS 308 pode fazer o download e armazenar em cache apenas o elemento do Período remoto associado com a BaseURL http://adserver.com/adl?id=”B”, com base no mapeamento discutido acima. O BM-SC 320 também pode entregar, em banda, uma MPD atualizada para a Apresentação de Mídia.
[0149] De acordo com o período de atualização mínimo de MPD, o cliente DASH 306 pode solicitar uma MPD atualizada do cliente MBMS 308. A MPD atualizada pode sinalizar um período remoto com Period@xlink:href = “http://adserver.com/adl?id=”B” e @xlink:actuate = “onLoad.” O cliente DASH 306 pode ainda solicitar o dereferenciamento do elemento de Período remoto através da emissão de um pedido GET de HTTP para a URL que aparece no @xlink:href. O cliente MBMS pode entregar o elemento de Período associado com BaseURL = “http://adserver.com/adl?id=”B.” Conforme o momento T1 se aproxima, o cliente DASH 306 pode buscar segmentos de conteúdo de anúncio descritos pelo elemento de Período remoto do cliente MBMS 308 (que tem armazenado em cache os segmentos no cache de proxy HTTP 312), e em seguida, fornecer os segmentos para o aplicativo de mídia (por exemplo, mecanismo de mídia 304).
[0150] Deste modo, as FIGs. 15A e 15B representam um exemplo de um método que inclui, por um cliente DASH: a determinação de um conjunto de identificadores de grupo de anúncio associados aos dados de mídia do anúncio de uma pluralidade de grupos de anúncio, sendo que os dados de mídia do anúncio devem ser reproduzidos durante um intervalo de anúncio publicitário para o principal conteúdo de mídia, selecionar, com base pelo menos em parte, nas características de um usuário para o cliente DASH, um dos grupos de anúncio do conjunto, recuperar dados de mídia do anúncio do grupo de anúncio selecionado, e fornecer os dados de mídia do anúncio para um aplicativo de mídia.
[0151] Da mesma forma, as FIGs. 15A e 15B representam um exemplo de um método que inclui, por uma unidade de middleware: receber dados de mídia de anúncio de um ou mais grupos de anúncio, receber um valor identificador para um dosgrupos de anúncio a partir de um streaming adaptativo dinâmico através do cliente HTTP (DASH) do dispositivo do cliente; extrair os dados da mídia de anúncio do grupo de anúnciocorrespondente ao valor do identificador; e fornecer os dados de mídia do anúncio extraídos para o cliente DASH.
[0152] Em um ou mais exemplos, as funções descritas podem ser implementadas em hardware, software, firmware ou qualquer combinação dos mesmos. Se implementadas em software, as funções podem ser armazenadas em ou transmitidas através de uma ou mais instruções ou código em uma mídia legível por computador e executadas por uma unidade de processamento baseada em hardware. A mídia legível por computador pode incluir a mídia de armazenamento legível por computador, que corresponde a uma mídia tangível, como mídia de armazenamento de dados ou mídia de comunicação, incluindo qualquer meio que facilite a transferência de um programa de computador de um lugar para outro, por exemplo, de acordo com um protocolo de comunicação. Deste modo, a mídia legível por computador pode geralmente corresponder a (1) mídia de armazenamento legível por computador tangível que é não-transitória ou (2) um meio de comunicação, como um sinal ou onda transportadora. A mídia de armazenamento de dados pode ser qualquer mídia disponível que pode ser acessada por um ou mais computadores ou um ou mais processadores para recuperar instruções, código, e/ou estruturas de dados para a implementação das técnicas descritas na presente revelação. Um produto de programa de computador pode incluir uma mídia legível por computador.
[0153] A título de exemplo, e não como limitação, tais mídias de armazenamento legíveis por computador podem 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 código de programa desejado sob a forma de instruções ou estruturas de dados e que pode ser acessado por um computador. Também, qualquer conexão é adequadamente chamada de uma mídia legível por computador. Por exemplo, se as instruções são transmitidas a partir de um site, servidor, ou de outra fonte remota através de um cabo coaxial, cabo de fibra óptica, par trançado, linha de assinante digital (DSL), ou tecnologias sem fios, tais como infravermelho, rádio e microondas, então o cabo coaxial, cabo de fibra óptica, par trançado, DSL, ou tecnologias sem fios, tais como infravermelho, rádio e microondas estão incluídas na definição de mídia de transmissão. Deve-se compreender, no entanto, que a mídia de armazenamento legível por computador e mídia de armazenamento de dados não incluem conexões, ondas transportadoras, sinais ou outra mídia trasnsitória, mas são, ao invés, direcionadas à mídia de armazenamento tangível, não transitória. Disco e disquete, como aqui utilizados, incluem disco compacto (CD), disco a laser, disco ótico, disco versátil digital (DVD), disquete e disco Blu-ray onde os disquetes geralmente reproduzem dados magneticamente, enquanto que os discos reproduzem dados oticamente com lasers. Combinações dos anteriores também devem ser incluídas dentro do escopo de mídias legíveis por computador.
[0154] As instruções podem ser executadas por um ou mais processadores, como um ou mais processadores de sinal digital (DSPs), microprocessadores de uso geral, circuitos integrados de aplicação específica (ASIC), arranjos de lógica programáveis em campo (FPGA), ou outros circuitos lógicos ou discretos equivalentes. Consequentemente, o termo “processador” como aqui utilizado pode referir-se a qualquer uma das estruturas precedentes ou qualquer outra estrutura adequada para implementação das técnicas aqui descritas. Além disso, em alguns aspectos, a funcionalidade aqui descrita pode ser fornecida dentro de módulos de hardware e/ou software dedicados configurados para a codificação e decodificação, ou incorporados em um codec combinado. Também, as técnicas podem ser totalmente implementadas em um ou mais circuitos ou elementos lógicos.
[0155] As técnicas da presente revelação podem ser implementadas em uma vasta variedade de dispositivos ou aparelhos, incluindo um monofone sem fios, um circuito integrado (IC) ou um conjunto de ICs (por exemplo, um conjunto de chips). Vários componentes, módulos ou unidades são descritos na presente revelação para enfatizar os aspectos funcionais dos dispositivos configurados para executar as técnicas divulgadas, mas não precisam necessariamente da realização por diferentes unidades de hardware. Em vez disso, como descrito acima, várias unidades podem ser combinadas em uma unidade de hardware de codec ou fornecida por uma coleta de unidades de hardware interoperativas, incluindo um ou mais processadores, conforme descrito acima, em conjunto com o software e/ou firmware adequado.
[0156] Vários exemplos foram descritos. Esses e outros exemplos estão dentro do escopo das reivindicações a seguir.
Claims (13)
1. Método para recuperar dados de mídia por um dispositivo cliente (152) que tem um cliente de serviço de multicast de multimídia, MBMS, (210) e um cliente de streaming adaptativo dinâmico sobre HTTP, DASH, (110, 204), compreendendo: determinar um conjunto de identificadores de grupo de anúncio associado aos dados de mídia de anúncio (168) de uma pluralidade de grupos de anúncio, sendo que os dados de mídia de anúncio (168) devem ser reproduzidos durante um intervalo de anúncio para o conteúdo de mídia principal (166), sendo que o conteúdo de mídia principal (166) está associado a um arquivo de manifesto (162); recuperar uma atualização para o arquivo de manifesto (164), sendo que a atualização define um período remoto que corresponde aos dados de mídia do anúncio (168), sendo que a atualização para o arquivo de manifesto especifica um modelo para um localizador de recurso uniforme, URL, da linguagem de conexão da linguagem de marcação extensível, XLink que inclui um atributo identificador; selecionar, com base, pelo menos em parte, nas características de um usuário para o cliente DASH (110), um dos grupos de anúncio a partir do conjunto; o método caracterizado pelo fato de que compreende adicionalmente: enviar dados representando o grupo de anúncio selecionado para o cliente de serviço de Broadcast Multicast de Multimídia, MBMS, do dispositivo cliente, os dados representando o grupo de anúncio selecionado que indica os dados de mídia de anúncio do grupo de anúncio selecionado e o período remoto a ser pré-buscado pelo cliente MBMS, e em que enviar os dados representando o grupo de mídia de anúncio selecionado compreende enviar os dados representando o grupo de mídia de anúncio selecionado separadamente de um URL XLink dereferenciado; atribuir, de acordo com o modelo, um valor identificador que corresponde ao grupo de anúncio selecionado para o atributo identificador do URL XLink; dereferenciar o URL XLink que inclui o valor identificador que corresponde ao grupo de anúncio selecionado para recuperar os dados de mídia de anúncio (168) pré-buscados do cliente MBMS (210) do dispositivo cliente, em que dereferenciar o URL XLink compreende enviar uma solicitação que especifica o URL XLink que inclui o valor identificador para o cliente MBMS (210) do dispositivo cliente; e fornecer os dados de mídia do anúncio (168) recuperados para um aplicativo de mídia (112, 202) .
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: receber o URL XLink que inclui o valor identificador do cliente DASH; receber dados para o período remoto através de um transporte de broadcast ou um transporte de multicast; determinar que os dados para o período remoto correspondem ao URL XLink quando uma tabela de entrega de arquivo, FDT, para o transporte de broadcast ou o transporte de multicast inclui um valor identificador que corresponde ao valor identificador do URL XLink; e em resposta à determinação de que os dados para o período remoto correspondem ao URL XLink, entregar os dados para o período remoto para o cliente DASH.
3. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que receber os dados para o período remoto compreende receber os dados para cada um dos grupos de anúncio.
4. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que receber os dados para o período remoto compreende descartar os dados para todos os grupos de anúncio diferentes do grupo de anúncio que corresponde ao valor identificador do URL XLink.
5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: receber o URL XLink que inclui o valor identificador do cliente DASH; receber dados para o período remoto através de um transporte de broadcast ou um transporte de multicast; determinar que os dados para o período remoto correspondem ao URL XLink quando um valor de um elemento de sintaxe groupIDFilter de um fragmento de descrição de filtro corresponde ao valor identificador do URL XLink; e em resposta à determinação de que os dados para o período remoto correspondem ao URL XLink, entregar os dados para o período remoto para o cliente DASH.
6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que recuperar compreende: obter dados que definem um período de atualização do arquivo de manifesto, em que recuperar a atualização compreende recuperar a atualização de acordo com o período de atualização do arquivo de manifesto.
7. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que os dados que definem o período de atualização do arquivo de manifesto compreendem um elemento MPD@minimumUpdatePeriod do arquivo de manifesto.
8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o arquivo de manifesto compreende uma descrição de apresentação de mídia.
9. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: fornecer, pelo cliente DASH, informações de estado relacionadas ao usuário ou dispositivo para um cliente MBMS do dispositivo cliente; receber, pelo cliente MBMS, os dados da mídia de anúncio através de um transporte de broadcast ou um transporte de multicast; e mapear, pelo cliente MBMS, as informações de estado para um identificador de grupo de anúncio único.
10. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que as informações de estado incluem um ou mais dentre cookies, informação de assinatura, dados de Preferência e Perfil do Usuário e histórico de uso.
11. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que selecionar compreende selecionar com base em pelo menos um dentre dados de preferências e perfil do usuário, histórico de consumo de conteúdo ou um mecanismo de recomendação de anúncio.
12. Memória legível por computador, caracterizada pelo fato de que tem instruções armazenadas na mesma que, quando executadas, fazem com que um processador de um dispositivo cliente (152) realize o método conforme definido em qualquer uma das reivindicações 1 a 11.
13. Dispositivo cliente (152) que tem um cliente de serviço de multicast de multimídia, MBMS, (210) e um cliente de streaming adaptativo dinâmico sobre HTTP, DASH, (110, 304), compreendendo: meios para determinar um conjunto de identificadores de grupo de anúncio associados a dados de mídia de anúncio (168) de uma pluralidade de grupos de anúncio, sendo que os dados de mídia de anúncio (168) devem ser reproduzidos durante um intervalo de anúncio para o conteúdo de mídia principal (166), sendo que o conteúdo de mídia principal (166) está associado a um arquivo de manifesto (162); meios para recuperar uma atualização para o arquivo de manifesto (164), sendo que a atualização define um período remoto que corresponde aos dados de mídia do anúncio (168), sendo que a atualização para o arquivo de manifesto especifica um modelo para um localizador de recurso uniforme, URL, da linguagem de conexão da linguagem de marcação extensível, XLink, que inclui um atributo identificador; meios para selecionar, com base, pelo menos em parte, nas características de um usuário para o cliente DASH (110), um dos grupos de anúncio a partir do conjunto; o dispositivo cliente caracterizado pelo fato de que compreende adicionalmente: meios para enviar dados representando o grupo de anúncio selecionado para o cliente de serviço de Broadcast Multicast de Multimídia, MBMS, do dispositivo cliente, os dados representando o grupo de anúncio selecionado que indica os dados de mídia de anúncio do grupo de anúncio selecionado e o período remoto a ser pré-buscado pelo cliente MBMS, e em que enviar os dados representando o grupo de mídia de anúncio selecionado compreende enviar os dados representando o grupo de mídia de anúncio selecionado separadamente de um URL XLink dereferenciado; meios para atribuir, de acordo com o modelo, um valor identificador que corresponde ao grupo de anúncio selecionado para o atributo identificador do URL XLink; meios para dereferenciar o URL XLink que inclui o valor identificador que corresponde ao grupo de anúncio selecionado para recuperar dados de mídia do anúncio (168) pré-buscados do grupo de anúncio selecionado e o período remoto do cliente MBMS (210) do dispositivo cliente, em que dereferenciar o URL XLink compreende enviar uma solicitação que especifica o URL XLink que inclui o valor identificador para o cliente MBMS (210) do dispositivo cliente (152); e meios para fornecer os dados de mídia de anúncio recuperados para um aplicativo de mídia (112, 202) .
Applications Claiming Priority (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201461969707P | 2014-03-24 | 2014-03-24 | |
| US61/969,707 | 2014-03-24 | ||
| US201461973063P | 2014-03-31 | 2014-03-31 | |
| US61/973,063 | 2014-03-31 | ||
| US14/665,500 US10902474B2 (en) | 2014-03-24 | 2015-03-23 | Targeted advertisement insertion for streaming media data |
| US14/665,500 | 2015-03-23 | ||
| PCT/US2015/022257 WO2015148513A1 (en) | 2014-03-24 | 2015-03-24 | Targeted advertisement insertion for streaming media data |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| BR112016022201A2 BR112016022201A2 (pt) | 2017-08-15 |
| BR112016022201A8 BR112016022201A8 (pt) | 2021-07-13 |
| BR112016022201B1 true BR112016022201B1 (pt) | 2023-12-12 |
Family
ID=54142548
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BR112016022201-6A BR112016022201B1 (pt) | 2014-03-24 | 2015-03-24 | 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 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US10902474B2 (pt) |
| EP (1) | EP3123734A1 (pt) |
| JP (1) | JP6612249B2 (pt) |
| CN (1) | CN106165434B (pt) |
| BR (1) | BR112016022201B1 (pt) |
| WO (1) | WO2015148513A1 (pt) |
Families Citing this family (55)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9258747B2 (en) * | 2013-09-17 | 2016-02-09 | Intel IP Corporation | User equipment and methods for fast handover failure recovery in 3GPP LTE network |
| AU2015218353A1 (en) | 2014-02-14 | 2016-09-01 | Pluto Inc. | Methods and systems for generating and providing program guides and content |
| CN105095216A (zh) * | 2014-04-22 | 2015-11-25 | 深圳市志友企业发展促进中心 | 一种数据组装方法、装置及资源传播系统 |
| US20160094986A1 (en) * | 2014-09-29 | 2016-03-31 | Sprint Communications Company L.P. | Content delivery metadata exchange in wireless communication systems |
| US10045058B2 (en) | 2014-10-23 | 2018-08-07 | At&T Intellectual Property I, L.P. | Method and apparatus to deliver a personalized media experience |
| EP3232668A4 (en) * | 2014-12-10 | 2018-06-13 | LG Electronics Inc. | Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method and broadcast signal reception method |
| WO2016105090A1 (ko) * | 2014-12-22 | 2016-06-30 | 엘지전자 주식회사 | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 |
| US10631037B2 (en) * | 2015-03-02 | 2020-04-21 | Nec Corporation | Decoding device, reception device, transmission device, transmission/reception system, decoding method, and storage medium having decoding program stored therein |
| WO2016199513A1 (ja) * | 2015-06-09 | 2016-12-15 | ソニー株式会社 | 受信装置、送信装置、およびデータ処理方法 |
| CN112019884B (zh) | 2015-07-06 | 2022-04-19 | Lg电子株式会社 | 发送广播信号的方法和设备及接收广播信号的方法和设备 |
| JP2018521589A (ja) * | 2015-07-08 | 2018-08-02 | コンヴィーダ ワイヤレス， エルエルシー | サービス層エニキャストおよびサムキャスト |
| WO2017102021A1 (en) * | 2015-12-18 | 2017-06-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Handling of content delivery in a client node |
| CN108605154B (zh) * | 2016-02-03 | 2022-02-25 | 联发科技股份有限公司 | 一种消息交互的方法和客户端设备 |
| US9942577B1 (en) * | 2016-02-23 | 2018-04-10 | Amazon Technologies, Inc. | Dynamic objects caching for media content playback |
| US11038938B2 (en) * | 2016-04-25 | 2021-06-15 | Time Warner Cable Enterprises Llc | Methods and apparatus for providing alternative content |
| US11039181B1 (en) | 2016-05-09 | 2021-06-15 | Google Llc | Method and apparatus for secure video manifest/playlist generation and playback |
| US11069378B1 (en) | 2016-05-10 | 2021-07-20 | Google Llc | Method and apparatus for frame accurate high resolution video editing in cloud using live video streams |
| US10595054B2 (en) | 2016-05-10 | 2020-03-17 | Google Llc | Method and apparatus for a virtual online video channel |
| US10785508B2 (en) | 2016-05-10 | 2020-09-22 | Google Llc | System for measuring video playback events using a server generated manifest/playlist |
| US10771824B1 (en) | 2016-05-10 | 2020-09-08 | Google Llc | System for managing video playback using a server generated manifest/playlist |
| US11032588B2 (en) | 2016-05-16 | 2021-06-08 | Google Llc | Method and apparatus for spatial enhanced adaptive bitrate live streaming for 360 degree video playback |
| US9872049B1 (en) * | 2016-06-30 | 2018-01-16 | SnifferCat, Inc. | Systems and methods for dynamic stitching of advertisements |
| US11076199B2 (en) * | 2016-09-29 | 2021-07-27 | Reliance Jio Infocomm Limited | Systems and methods for providing targeted content in an EMBMS stream to a user device |
| WO2018125269A1 (en) * | 2016-12-30 | 2018-07-05 | Google Llc | Systems and methods for interrupting streaming content provided via an inviolate manifest protocol |
| US9872062B1 (en) * | 2017-02-22 | 2018-01-16 | Wyse Technology L.L.C. | Enforcing synchronization by embedding audio within video frame data |
| US11062497B2 (en) * | 2017-07-17 | 2021-07-13 | At&T Intellectual Property I, L.P. | Structuralized creation and transmission of personalized audiovisual data |
| JP6633244B2 (ja) * | 2017-08-15 | 2020-01-22 | グーグル エルエルシー | マルチキャストを使用するストリーミング帯域幅の最適化された利用 |
| EP3602319A1 (en) * | 2017-08-16 | 2020-02-05 | Google LLC | Dynamic content loading selection |
| WO2019069326A1 (en) * | 2017-10-06 | 2019-04-11 | Nilesh Suryawanshi | METHOD AND APPARATUS FOR REPLACING ADVERTISING BY EXTRACTING METADATA |
| US11310540B2 (en) * | 2017-11-10 | 2022-04-19 | Qualcomm Incorporated | Interfaces between dash aware application and dash client for service interactivity support |
| CN108040267A (zh) * | 2017-12-07 | 2018-05-15 | 北京奇虎科技有限公司 | 一种在视频中融合推荐内容的方法和装置 |
| CN108122198A (zh) * | 2017-12-07 | 2018-06-05 | 北京奇虎科技有限公司 | 一种在视频中融合推荐内容的实现方法、装置和服务器 |
| US20190238950A1 (en) * | 2018-01-31 | 2019-08-01 | Qualcomm Incorporated | Dynamic conditional advertisement insertion |
| US10938872B2 (en) * | 2018-03-12 | 2021-03-02 | Qualcomm Incorporated | Processing interactivity events for streaming media data |
| EP4343660A3 (en) | 2018-05-09 | 2024-06-05 | Pluto Inc. | Methods and systems for generating and providing program guides and content |
| US11533527B2 (en) | 2018-05-09 | 2022-12-20 | Pluto Inc. | Methods and systems for generating and providing program guides and content |
| US11514532B1 (en) | 2018-06-12 | 2022-11-29 | United Services Automobile Association (Usaa) | Transaction data transfer management |
| US10951960B1 (en) * | 2018-07-17 | 2021-03-16 | Amazon Technologies, Inc. | Dynamic content insertion |
| US10965966B1 (en) * | 2018-07-17 | 2021-03-30 | Amazon Technologies, Inc. | Dynamic content insertion |
| US20200112753A1 (en) * | 2018-10-03 | 2020-04-09 | Qualcomm Incorporated | Service description for streaming media data |
| US11184665B2 (en) | 2018-10-03 | 2021-11-23 | Qualcomm Incorporated | Initialization set for network streaming of media data |
| WO2020125783A1 (zh) * | 2018-12-20 | 2020-06-25 | 青岛海信电器股份有限公司 | 广播信号接收装置以及广播信号接收方法 |
| US11356715B2 (en) * | 2018-12-28 | 2022-06-07 | Tencent America LLC | Dynamic shortening of advertisement duration during live streaming |
| US11144956B1 (en) * | 2019-02-14 | 2021-10-12 | Amazon Technologies, Inc. | Targeted media delivery based on previous consumer interactions |
| FR3094167B1 (fr) * | 2019-03-18 | 2021-04-23 | Ateme | Procédé de gestion de contenus multimédia et dispositif pour la mise en œuvre du procédé |
| WO2020247922A1 (en) | 2019-06-07 | 2020-12-10 | The Nielsen Company (Us), Llc | Content-modification system with system resource request feature |
| US11509972B2 (en) * | 2019-07-09 | 2022-11-22 | Dolby International Ab | Method and device for personalization of media data for playback |
| US11178433B2 (en) * | 2019-11-21 | 2021-11-16 | Pluto Inc. | Methods and systems for dynamic routing of content using a static playlist manifest |
| JP2023517485A (ja) * | 2020-02-28 | 2023-04-26 | フル・エルエルシー | 動的要素置換のためのグループ中の要素の識別 |
| BR112022016916A2 (pt) | 2020-02-28 | 2022-10-25 | Hulu Llc | Armazenamento de resoluções de elementos remotos baseado no cliente |
| US11930254B2 (en) * | 2020-04-07 | 2024-03-12 | Tencent America LLC | Patchable remote element for data manipulation |
| WO2022165066A1 (en) * | 2021-01-27 | 2022-08-04 | Arris Enterprises Llc | Systems and methods for delay manifests in abr content delivery |
| 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 |
| US11509946B1 (en) | 2021-11-08 | 2022-11-22 | Pluto Inc. | Methods and systems configured to manage video transcoder latencies |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070027751A1 (en) | 2005-07-29 | 2007-02-01 | Chad Carson | Positioning advertisements on the bases of expected revenue |
| KR101599743B1 (ko) | 2009-04-21 | 2016-03-16 | 삼성전자주식회사 | 휴대 방송망을 이용한 휴대 광고 제공 장치, 방법 및 광고 서버 그리고 그 시스템 |
| US8621520B2 (en) | 2009-05-19 | 2013-12-31 | Qualcomm Incorporated | Delivery of selective content to client applications by mobile broadcast device with content filtering capability |
| US9026671B2 (en) | 2011-04-05 | 2015-05-05 | Qualcomm Incorporated | IP broadcast streaming services distribution using file delivery methods |
| US8849950B2 (en) | 2011-04-07 | 2014-09-30 | Qualcomm Incorporated | Network streaming of video data using byte range requests |
| US9591361B2 (en) | 2011-09-07 | 2017-03-07 | Qualcomm Incorporated | Streaming of multimedia data from multiple sources |
| IN2015DN00468A (pt) | 2012-07-09 | 2015-06-26 | Ericsson Telefon Ab L M | |
| US20150149279A1 (en) * | 2013-11-22 | 2015-05-28 | Cellco Partnership D/B/A Verizon Wireless | Targeted advertising for broadcasted content |
-
2015
- 2015-03-23 US US14/665,500 patent/US10902474B2/en active Active
- 2015-03-24 EP EP15718010.0A patent/EP3123734A1/en not_active Ceased
- 2015-03-24 BR BR112016022201-6A patent/BR112016022201B1/pt active IP Right Grant
- 2015-03-24 JP JP2016558191A patent/JP6612249B2/ja not_active Expired - Fee Related
- 2015-03-24 CN CN201580015755.1A patent/CN106165434B/zh active Active
- 2015-03-24 WO PCT/US2015/022257 patent/WO2015148513A1/en active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| CN106165434A (zh) | 2016-11-23 |
| US20150269629A1 (en) | 2015-09-24 |
| JP6612249B2 (ja) | 2019-11-27 |
| US10902474B2 (en) | 2021-01-26 |
| WO2015148513A1 (en) | 2015-10-01 |
| BR112016022201A2 (pt) | 2017-08-15 |
| EP3123734A1 (en) | 2017-02-01 |
| CN106165434B (zh) | 2019-10-18 |
| BR112016022201A8 (pt) | 2021-07-13 |
| JP2017517167A (ja) | 2017-06-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10902474B2 (en) | Targeted advertisement insertion for streaming media data | |
| US20230283863A1 (en) | Retrieving and accessing segment chunks for media streaming | |
| US9319448B2 (en) | Trick modes for network streaming of coded multimedia data | |
| JP5937275B2 (ja) | ネットワークストリーミングのための失われたメディアデータの置換 | |
| US20160337424A1 (en) | Transferring media data using a websocket subprotocol | |
| BR112020015214A2 (pt) | inserção dinâmica de anúncio condicional | |
| TW201711431A (zh) | 超級本文傳輸協定上動態自適應串流客戶經驗品質度量之中間軟體傳遞 | |
| US11321516B2 (en) | Processing dynamic web content of an ISO BMFF web resource track | |
| US20150312303A1 (en) | Determining whether to use sidx information when streaming media data | |
| US20180176278A1 (en) | Detecting and signaling new initialization segments during manifest-file-free media streaming | |
| BR112020022899A2 (pt) | sinalizar, em um arquivo de manifesto, seções ausentes de dados de mídia para rede de fluxo contínuo | |
| WO2017196980A1 (en) | Real-time control interface for broadcast object streaming | |
| KR20160138044A (ko) | 미디어 데이터를 스트리밍하기 위한 목표된 광고 삽입 | |
| EP4128809A1 (en) | Determination of availability of chunks of data for network streaming media data | |
| BR112017027511B1 (pt) | Distribuição de middleware de métricas de qoe de cliente dash | |
| 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 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B06U | Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette] | ||
| B350 | Update of information on the portal [chapter 15.35 patent gazette] | ||
| B07A | Application suspended after technical examination (opinion) [chapter 7.1 patent gazette] | ||
| B09A | Decision: intention to grant [chapter 9.1 patent gazette] | ||
| B16A | Patent or certificate of addition of invention granted [chapter 16.1 patent gazette] |
Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 24/03/2015, OBSERVADAS AS CONDICOES LEGAIS |