BR112019014070A2 - dados de sinalização para suporte de pré-busca para transmissão contínua de dados de mídia - Google Patents

dados de sinalização para suporte de pré-busca para transmissão contínua de dados de mídia Download PDF

Info

Publication number
BR112019014070A2
BR112019014070A2 BR112019014070A BR112019014070A BR112019014070A2 BR 112019014070 A2 BR112019014070 A2 BR 112019014070A2 BR 112019014070 A BR112019014070 A BR 112019014070A BR 112019014070 A BR112019014070 A BR 112019014070A BR 112019014070 A2 BR112019014070 A2 BR 112019014070A2
Authority
BR
Brazil
Prior art keywords
data
media
information
dash
video
Prior art date
Application number
BR112019014070A
Other languages
English (en)
Inventor
Stockhammer Thomas
Wang Ye-Kui
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of BR112019014070A2 publication Critical patent/BR112019014070A2/pt

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • 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/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/44029—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • 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/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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]

Landscapes

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

Abstract

dados de sinalização para suporte de pré-busca para transmissão contínua de dados de mídia trata-se de um dispositivo de mídia que pré-busca dados de mídia que são prováveis de serem recuperados. um dispositivo de mídia exemplificativo inclui uma memória para armazenar dados de mídia e um ou mais processadores implementados no conjunto de circuitos e configurados para receber informações que indicam pelo menos uma estrutura de dados de uma pluralidade de estruturas de dados que é provável de ser recuperada por uma pluralidade de dispositivos de usuário operada por uma respectiva pluralidade de usuários, em que a estrutura de dados inclui dados de mídia e para recuperar os dados de mídia da estrutura de dados antes de receber solicitações para os dados de mídia dos dispositivos de usuário. as informações podem ser incluídas em, por exemplo, um arquivo de manifesto, uma mensagem de entrega de melhoria de parâmetros especial (ped) e/ou uma faixa separada de um arquivo de vídeo multiplexado com outras faixas do arquivo de vídeo.

Description

DADOS DE SINALIZAÇÃO PARA SUPORTE DE PRÉ-BUSCA PARA TRANSMISSÃO CONTÍNUA DE DADOS DE MÍDIA [0001] Este pedido reivindica o beneficio do Pedido Provisório U.S. N° 62/444,730, arquivado em 10 de janeiro de 2017, cujos conteúdo inteiros são incorporados a titulo de referência pelo presente documento.
CAMPO DA TÉCNICA [0002] Essa revelação se refere ao transporte de dados de midia codificados.
ANTECENDENTES [0003] As capacidades de video digital podem ser incorporadas em uma faixa ampla de dispositivos, incluindo televisões digitais, sistemas de difusão direta digital, sistemas de difusão sem fio, assistentes digitais pessoais (PDAs), computadores do tipo laptop ou do tipo desktop, câmeras digitais, dispositivos de registro digital, tocadores de midia digital, dispositivos de jogo de video, consoles de video game, telefones de rádio por satélite e celulares, dispositivos de teleconferência de video e similares. Os dispositivos de video digital implantam técnicas de compressão de video, como aquelas descritas nos padrões definidos por ITU-T H.261, ISO/IEC MPEG-1 Visual, ITU-T H.262 ou ISO/IEC MPEG-2 Visual, MPEG2, MPEG-4, ITU-T H.263 ou ITU-T H.264/MPEG-4 Visual, Parte 10, Codificação de Video Avançado (AVC), ITU-T H.265 (chamado também de Codificação de Video de Alta Eficiência (HEVC) e ISO/IEC 23008-2), e extensões de tais padrões como Codificação de Video Escalável (SVC) e Codificação de Video de Multivisualização (MVC) para transmitir e receber
Petição 870190063436, de 08/07/2019, pág. 6/102
2/78 informações de video digital mais eficientemente. Extensões de HEVC incluem sua extensão de codificação escalável (isto é, codificação de video de alta eficiência escalável, SHVC) e sua extensão de multivisualização (isto é, codificação de video de alta eficiência de multivisualização, MV-HEVC).
[0004] Após os dados de video serem codificados, os dados de video podem ser empacotados para transmissão ou armazenamento. Os dados de video podem ser montados em um arquivo de video em conformação com qualquer um de uma variedade de padrões, como o formato e de arquivo de midia de base da Organização Internacional de Padronização (ISO) e extensões do mesmo, como AVC.
SUMÁRIO [0005] Em geral, essa revelação descreve técnicas para sinalizar informações que indicam que certos dados são mais prováveis de serem usados que outros dados, por exemplo, durante a transmissão continua ou outro transporte dos dados. Tais informações podem ser usadas para pré-busca de dados pelos dispositivos de cliente ou pelos elementos de rede intermediários entre os clientes e um servidor original em sistemas de transmissão continua adaptável. Em particular, um dispositivo de midia pode usar técnicas desta revelação para pré-buscar os dados que são mais prováveis de serem usados.
[0006] Em um exemplo, um método de recuperação de dados de midia inclui receber, por um dispositivo de midia, informações que indicam pelo menos uma estrutura de dados de uma pluralidade de estruturas de dados que é provável de ser recuperada por uma pluralidade de
Petição 870190063436, de 08/07/2019, pág. 7/102
3/78 dispositivos de usuários operados por uma respectiva pluralidade de usuários, a estrutura de dados incluindo dados de midia e recuperando, pelo dispositivo de midia, os dados de midia da estrutura de dados antes de receber solicitações para os dados de midia dos dispositivos de usuário.
[0007] Em um outro exemplo, um dispositivo de midia para recuperar dados de midia inclui uma memória para armazenar dados de midia e um ou mais processadores implementados no conjunto de circuitos e configurados para receber informações que indicam pelo menos uma estrutura de dados de uma pluralidade de estruturas de dados que é provável de ser recuperada por uma pluralidade de dispositivos de usuário operada por uma respectiva pluralidade de usuários, a estrutura de dados incluindo dados de midia, e recuperar os dados de midia da estrutura de dados antes de receber solicitações para os dados de midia dos dispositivos de usuário.
[0008] Em um outro exemplo, um dispositivo de midia para recuperar dados de midia inclui meios para receber informações que indicam pelo menos uma estrutura de dados de uma pluralidade de estruturas de dados que é provável de ser recuperada por uma pluralidade de dispositivos de usuário operada por uma respectiva pluralidade de usuários, a estrutura de dados incluindo dados de midia e meios para recuperar os dados de midia da estrutura de dados antes de receber solicitações para os dados de midia dos dispositivos de usuário.
[000 9] Em um outro exemplo, um meio de
Petição 870190063436, de 08/07/2019, pág. 8/102
4/78 armazenamento legível por computador tem armazenado instruções no mesmo que, quando executadas, fazem com que um processador de um dispositivo de mídia receba informações que indicam pelo menos uma estrutura de dados de uma pluralidade de estruturas de dados que é provável de ser recuperada por uma pluralidade de dispositivos de usuário operada por uma respectiva pluralidade de usuários, a estrutura de dados incluindo dados de mídia, e recupere os dados de mídia da estrutura de dados antes de receber solicitações para os dados de mídia dos dispositivos de usuário.
[0010] Os detalhes de um ou mais exemplos são apresentados nos desenhos anexos e na descrição abaixo. Outros recursos, objetivos e vantagens estarão evidentes a partir da descrição e dos desenhos, a partir das reivindicações.
BREVE DESCRIÇÃO DE DESENHOS [0011] A Figura 1 é um diagrama de bloco que ilustra um sistema exemplificador que implementa técnicas para transmissão contínua dados de mídia por uma rede.
[0012] A Figura 2 é um diagrama de bloco que ilustra um conjunto de componentes exemplificativo de uma unidade de recuperação da Figura 1 em maior detalhe.
[0013] A Figura 3 é um diagrama conceituai que ilustra um conteúdo multimídia exemplificador.
[0014] A Figura 4 é um diagrama de bloco que ilustra elementos de um arquivo de vídeo exemplificativo, que pode corresponder a um segmento de uma representação.
[0015] A Figura 5 é um fluxograma que ilustra
Petição 870190063436, de 08/07/2019, pág. 9/102
5/78 um método exemplificative para realizar as técnicas desta revelação .
[0016] A Figura 6 é um fluxograma que ilustra um método exemplificativo para realizar as técnicas desta revelação.
DESCRIÇÃO DETALHADA [0017] Em geral, essa revelação descreve técnicas para sinalizar dados para suporte de pré-busca para transmissão continua de dados de mídia, como o uso de Transmissão Contínua Adaptativa Dinâmica por HTTP (DASH). A DASH é descrita em, por exemplo, Projeto de Parceria de 3a Geração; Serviços de Grupo de Especificação Técnica e Aspectos de Sistema; Serviço de Transmissão Contínua de Pacote Comutado ponta a ponta Transparente (PSS); Download Progressivo e Transmissão Contínua Adaptativa Dinâmica por HTTP (3GP-DASH) (Versão 12) (dezembro de 2013) . A DASH é especificada também em Information technology — Dynamic adaptive streaming over HTTP (DASH)— Part 1 : Media presentation description and segment formats, ISO/IEC 23009-1 (1 de abril de 2012) .
[0018] Embora discutido principalmente em relação à DASH com propósitos de explicação e exemplo, deve ser entendido que essas técnicas podem ser aplicadas a outras tecnologias de transmissão contínua. Por exemplo, as técnicas desta revelação podem ser realizadas em conjunto com a Transmissão Contínua (HLS) ao Vivo de HTTP Apple ou Formato de Aplicação de Mídia Comum (CMAF). As técnicas desta revelação podem ser realizadas em conjunto com a Transmissão Contínua Suave da Microsoft.
Petição 870190063436, de 08/07/2019, pág. 10/102
6/78 [0019] Conforme discutido em maior detalhe abaixo, os protocolos de midia de transmissão continua envolvem frequentemente transmitir um arquivo de manifesto a partir de um dispositivo de servidor para um dispositivo de cliente, em que o arquivo de manifesto descreve características de uma apresentação de mídia correspondente. Por exemplo, na DASH, uma descrição de apresentação de mídia (MPD) descreve conjuntos de adaptação que incluem representações comutáveis. Cada uma das representações inclui uma pluralidade de segmentos, ou seja, arquivos individualmente recuperáveis (que podem ser associados com um localizador de recurso uniforme correspondente (URL)).
[0020] As técnicas desta revelação incluem, em geral, sinalizar informações que indicam qual estrutura de dados de uma pluralidade de estruturas de dados é mais provável de ser recuperada (por exemplo, por um dispositivo de usuário), de modo que um dispositivo de mídia possa prébuscar dados de mídia da estrutura de dados. Por exemplo, a estrutura de dados pode ser uma apresentação de mídia particular (por exemplo, um título de filme particular), um conjunto de adaptações particular de uma apresentação de mídia, uma representação de uma apresentação de mídia ou até mesmo um conjunto de segmentos de uma representação. As informações podem formar parte de um arquivo de manifesto (como uma MPD) no nível de arquivo de manifesto ou em um nível de representação ou nível de conjunto de adaptações (por exemplo, dentro da MPD). Adicional ou alternativamente, as informações podem ser sinalizadas as
Petição 870190063436, de 08/07/2019, pág. 11/102
7/78 informações secundárias separadamente a partir do arquivo de manifesto, por exemplo, para dispositivos de rede intermediária, como elemento de rede de reconhecimento de midias (MANEs) ou elemento de rede de reconhecimento de DASHs (DANEs).
[0021]
Conforme observado acima segmentos em
DASH são exemplos de arquivos individualmente recuperáveis. Em geral, tais arquivos podem ser formatados de acordo com o Formato de Arquivo de Midia de Base ISO (ISOBMFF) ou uma extensão para ISOBMFF. As técnicas desta revelação podem ser aplicadas a arquivos de video em conformidade com os dados de video encapsulados de acordo com qualquer um dentre ISO BMFF, formato de arquivo de Codificação Escalável de Video (SVC), formato de arquivo de Codificação Avançada de Video (AVC), formato de arquivo de Projeto de Parceria de Terceira Geração (3GPP) e/ou formato de arquivo de Codificação de Video de Multivisualização (MVC) ou outros formatos de arquivo de video similares.
[0022]
Os padrões de formato de arquivo incluem o formato de arquivo de midia de base (ISOBMFF, ISO/IEC 14496-12) e outros padrões derivados do ISOBMFF, incluindo formato de arquivo MPEG-4 (ISO/IEC 14496-15), formato de arquivo 3 GPP (3 GPP TS 26.244) e formatos de arquivo para familias AVC e HEVC de codecs de video (ISO/IEC 14496-15) . Os textos preliminares de edições para ISO/IEC 14496-12 de 14496-15 estão disponíveis em phenix.intevry.fr/mpeg/doc_end_usuário/documents/11l_Geneva/wgll/wl51 77-v6-wl5177.zip e
Petição 870190063436, de 08/07/2019, pág. 12/102
8/78 wgl1.sc2 9.org/doc_end_usuário/documents/115_Geneva/wgll/W16 169-V2 -wl6169.zip, respectivamente. 0 ISOBMFF é usado como base para muitos formatos de encapsulamento de codec, como o formato de arquivo AVC, assim como para muitos formatos de pacote de multimidia, como o formato de arquivo MPEG-4, o formato de arquivo 3 GPP (3GP) e o formato de arquivo de difusão de video digital (DVB).
[0023] Além da midia continua, como áudio, video, a midia estática, como imagens, assim como metadados podem ser armazenados em um arquivo em conformidade com o ISOBMFF. Os arquivos estruturados de acordo com o ISOBMFF podem ser usados para muitos propósitos, incluindo reprodução de arquivo de video local, transferência por download progressiva de um arquivo remoto, segmentos para DASH, pacotes para conteúdo para serem transmitidos continuamente e suas instruções de pacotes e registro de registro de transmissões continuas de midia recebidos em tempo real.
[0024] Uma caixa é uma estrutura de sintaxe elementar no ISOBMFF, que inclui um tipo de caixa codificada de quatro caracteres, uma contagem de byte para a caixa, e uma carga útil. Um arquivo ISOBMFF inclui uma sequência de caixas, e as caixas podem conter outras caixas. Uma caixa de Filme (moov) contém os metadados para as transmissões continuas de midia continua presente no arquivo, cada um representado no arquivo como uma faixa. Os metadados para uma faixa são abrangidos em uma caixa de Faixa (trak), enquanto o conteúdo de midia de uma faixa é abrangido em uma caixa de Dados de Midia (mdat) ou
Petição 870190063436, de 08/07/2019, pág. 13/102
9/78 diretamente em um arquivo separado. 0 conteúdo de midia para faixas inclui uma sequência de amostras, como unidades de acesso de áudio ou de video.
[0025] O ISOBMFF especifica os tipos a seguir de faixas: uma faixa de midia que contém uma transmissão continua de midia elementar; uma faixa de indicação que inclui instruções de transmissão de midia ou representa uma transmissão continua de pacote recebida e uma faixa de metadados cronometrados que compreende metadados sincronizados por tempo. Embora projetado originalmente para armazenamento, o ISOBMFF tem provado ser muito valioso para transmissão continua, por exemplo, para download progressiva ou DASH. Para propósitos de transmissão continua, os fragmentos de filme definidos em ISOBMFF podem ser usados.
[0026] Os metadados para cada faixa inclui uma lista de entradas de descrição de amostra, cada uma fornecendo o formato de codificação ou de encapsulamento usado na faixa e os dados de inicialização necessários para o processamento esse formato. Cada amostra é associada com uma das entradas de descrição de amostra da faixa.
[0027] O ISOBMFF possibilita a especificação de metadados especificados por amostra com vários mecanismos. As caixas especificas contidas na caixa de Tabela de Amostra (stbl) têm sido padronizadas para responder às necessidades comuns. Por exemplo, uma caixa de Amostra de Sinc (stss) é usada para listar as amostras de acesso aleatório da faixa. O mecanismo de grupamento de amostra possibilita o mapeamento de amostras de acordo com
Petição 870190063436, de 08/07/2019, pág. 14/102
10/78 um tipo de grupamento de quatro caracteres em grupos de amostras que compartilham a mesma propriedade especificada como uma entrada de descrição de grupo no arquivo. Vários tipos de grupamento foram especificados no ISOBMFF.
[0028] Na transmissão continua de HTTP, como de acordo com a DASH, as operações frequentemente usadas incluem HEAD, GET e GET parcial. A operação de HEAD recupera um cabeçalho de um arquivo associado com um determinado localizador de recurso uniforme (URL) ou nome de recurso uniforme (URN) sem recuperar uma carga útil associada com o URL ou URN. A operação de GET recupera todo um arquivo associado com um determinado URL ou URN. A operação de GET parcial recebe uma faixa de byte como um parâmetro de entrada e recupera um número continuo de bytes de um arquivo, em que o número de bytes correspondente para a faixa de byte recebida. Assim, fragmentos de filme podem ser fornecidos para transmissão continua de HTTP, devido a uma operação de GET parcial poder obter um ou mais fragmentos de filme individuais. Em um fragmento de filme, podem ser vários fragmentos de faixa de faixas diferentes. Na transmissão continua de HTTP, uma apresentação de midia pode ser uma coleção estruturada de dados que é acessível ao cliente. O cliente pode solicitar e transferir por download informações de dados de midia para apresentar um serviço de transmissão continua para um usuário.
[0029] No exemplo de DASH, podem ser múltiplas representações para dados de video e/ou áudio de conteúdo multimidia. Conforme explicado abaixo, representações diferentes podem corresponder a características de
Petição 870190063436, de 08/07/2019, pág. 15/102
11/78 codificação diferentes (por exemplo, perfis ou niveis diferentes de um padrão de codificação de video), a padrões de codificação ou extensões de padrões de codificação diferentes (como extensões de multivisualização e/ou moduláveis) ou a taxas de bits diferentes. 0 manifesto de tais representações pode ser definido em uma estrutura de dados de Descrição de Apresentação de Midia (MPD) . Uma apresentação de midia pode corresponder a uma coleção estruturada de dados que é acessível a um dispositivo de cliente de transmissão continua de HTTP. 0 dispositivo de cliente de transmissão continua de HTTP pode solicitar e transferir por download dados de midia informações para apresentar um serviço de transmissão continua para um usuário do dispositivo de cliente. Uma apresentação de midia pode ser descrita na estrutura de dados de MPD, que pode incluir atualizações da MPD.
[0030] Uma apresentação de midia pode conter uma sequência de um ou mais Periodos. Cada periodo pode se estender até o inicio do próximo Periodo ou até o fim da apresentação de midia, no caso do último periodo. Cada periodo pode conter uma ou mais representações para o mesmo conteúdo de midia. Uma representação pode ser uma dentre diversas versões codificadas alternativas de áudio, video, texto cronometrado ou outros tais dados. As representações podem diferir por tipos de codificação, por exemplo, por taxa de bits, resolução e/ou codec para dados de video e taxa de bits, idioma e/ou codec para dados de áudio. O termo representação pode ser usado para se referir a uma seção de dados de áudio ou de video decodificados
Petição 870190063436, de 08/07/2019, pág. 16/102
12/78 correspondente a um período particular do conteúdo multimídia e codificado de uma forma particular.
[0031] As representações de um período particular podem ser atribuídas a um grupo indicado por um atributo na MPD indicativa de um conjunto de adaptações ao qual as representações pertencem. As representações no mesmo conjunto de adaptações são, em geral, consideradas alternativas entre si, em que um dispositivo de cliente pode comutar dinâmica e perfeitamente entre essas representações, por exemplo, para realizar adaptação de largura de banda. Por exemplo, cada representação de dados de vídeo para um período particular pode ser atribuída ao mesmo conjunto de adaptações, de modo que qualquer uma das representações possa ser selecionada para decodificação para apresentar dados de mí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 contido em um período pode ser representado por uma representação do grupo 0, se presente, ou pela combinação de, no máximo, uma representação de cada grupo diferente de zero, em alguns exemplos. Os dados de temporização para cada representação de um período podem ser expressados relativos ao tempo inicial do período.
[0032] 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 autoinicializável. Quando presente, o segmento de inicialização pode conter informações de inicialização para acessar a representação. Em geral, o segmento de
Petição 870190063436, de 08/07/2019, pág. 17/102
13/78 inicialização não contém dados de mídia. Um segmento pode ser referenciado exclusivamente por um identificador, como um localizador de recurso uniforme (URL), um nome de recurso uniforme (URN) ou um identificador de recurso uniforme (URI). A MPD pode fornecer os identificadores para cada segmento. Em alguns exemplos, a MPD pode fornecer também faixa de bytes sob forma de um atributo de faixa, que pode corresponder aos dados para um segmento contido em um arquivo acessível pelo URL, URN ou URI.
[0033] Representações diferentes podem ser selecionadas para recuperação substancialmente simultânea de tipos diferentes de dados de mídia. Por exemplo, um dispositivo de cliente pode selecionar uma representação de áudio, uma representação de vídeo e uma representação de texto cronometrado a partir das quais se recupera os segmentos. Em alguns exemplos, o dispositivo de cliente pode selecionar conjuntos de adaptação particulares para realizar adaptação de largura de banda. Ou seja, o dispositivo de cliente pode selecionar um conjunto de adaptações que inclui representações de vídeo, um conjunto de adaptações que inclui representações de áudio e/ou um conjunto de adaptações que inclui texto cronometrado. Alternativamente, o dispositivo de cliente pode selecionar conjuntos de adaptação para certos tipos de mídia (por exemplo, vídeo) e selecionar diretamente representações para outros tipos de mídia (por exemplo, áudio e/ou texto cronometrado).
[0034] A DASH é um padrão para aplicações de transmissão contínua de HTTP (adaptativas). A DASH
Petição 870190063436, de 08/07/2019, pág. 18/102
14/78 especifica principalmente o formato da descrição de apresentação de midia (MPD), um exemplo de um arquivo de manifesto, e o formato de segmento de midia. A MPD descreve a mídia disponível em um dispositivo de servidor e deixa que o cliente de DASH transfira por download autonomamente a versão de mídia em um tempo de mídia particular de interesse [0035] Um procedimento típico para DASH com base na transmissão contínua de HTTP inclui as etapas a seguir:
1. Um dispositivo de cliente obtém uma MPD de um conteúdo de transmissão contínua (apresentação de mídia), por exemplo, um filme. A MPD inclui informações em representações alternativas diferentes, por exemplo, taxa de bits, resolução de vídeo, taxa de quadro, idioma de áudio, do conteúdo de transmissão contínua, assim como URLs de recursos de HTTP (um segmento de inicialização e os segmentos de mídia).
2. Com base nas informações na MPD e nas informações locais de cliente, por exemplo, largura de banda de rede, capacidades de decodificação/exibição preferência de usuário, o cliente solicita a representação(representações) desejada, um segmento (ou uma parte do mesmo) por vez.
3. Quando o cliente detecta uma alteração de largura de banda de rede, o mesmo solicita segmentos de uma representação diferente com uma taxa de bits mais bem compatível, iniciando idealmente a partir de um segmento que inicia com ponto de acesso aleatório (RAP).
Petição 870190063436, de 08/07/2019, pág. 19/102
15/78 [0036] Durante uma sessão de transmissão contínua de HTTP para responder à solicitação de usuário para voltar a uma posição anterior ou encaminhar para uma posição futura (chamada também de modos de truque), o dispositivo de cliente solicita segmentos anteriores ou futuros que eu iniciam a partir de um segmento que está próximo à posição desejada e que inicia idealmente com um ponto de acesso aleatório. O usuário pode solicitar também avançar o conteúdo (um outro exemplo de um modo de truque), que pode ser realizado pela solicitação de dados suficientes para decodificar apenas as imagens de vídeo codificadas internamente ou apenas um subconjunto temporal da transmissão contínua de vídeo.
[0037] O ISO/IEC 23009-5 especifica a DASH assistida por Rede e Servidor (SAND).A SAND introduz mensagens trocadas entre dispositivos de cliente de DASH e elementos de rede ou entre vários elementos de rede, com o propósito de aprimorar a eficiência de sessões de transmissão contínua pelo fornecimento de informações sobre características operacionais em tempo real de redes, de servidores, de proxies, caches, de redes de entrega de conteúdo (CDNs), assim como de desempenho e estado de cliente.
[0038] Na SAND, um elemento de rede que tem pelo menos inteligência mínima sobre a DASH é chamado de um Elemento de Rede de Reconhecimento de DASH (DANE) . Os DANEs, por exemplo, podem ser configurados para reconhecer objetos entregues formatados por DASH, como os segmentos de MPD ou DASH, e podem priorizar, analisar ou até mesmo
Petição 870190063436, de 08/07/2019, pág. 20/102
16/78 modificar tais objetos. Um servidor original de DASH é considerado também como um DANE.
[0039]
As mensagens de
SAND se refere a mensagens trocadas entre clientes de DASH, DANEs, e/ou Servidores de Métrica a fim de melhorar recepção ou entrega de serviço de DASH, ou relatar situação ou métrica do cliente de DASH para Elementos de Rede de reconhecimento de DASH ou Servidores de Métrica. As mensagens de SAND são categorizadas nos quatro tipos a seguir:
• mensagens de Entrega de Melhoria de Parâmetros (PED) que são trocadas entre os DANEs, • mensagens de Recepção de Melhoramento de Parâmetros (PER) que são enviadas a partir de DANEs para clientes de DASH, • Mensagens de situação que são enviadas a partir de clientes de DASH para DANEs, e • Mensagens de métrica que são enviadas a partir de clientes de DASH para servidores de Métrica.
[0040]
As mensagens de situação definidas na
SAND incluem uma mensagem de SAND de AnticipatedRequests, que permitem que um cliente de DASH anuncie para um DANE qual conjunto especifico de segmentos está interessado. A intenção é sinalizar o conjunto de segmentos em representações que o cliente de DASH provavelmente logo seleciona e solicita. Atualmente, não há mensagens de PED definidas na SAND.
[0041]
A realidade virtual (RV) é a habilidade de estar virtualmente presente em um mundo não fisico criado por renderização de imagens e sons naturais e/ou
Petição 870190063436, de 08/07/2019, pág. 21/102
17/78 sintéticos correlacionados pelos movimentos de um usuário imerso, permitindo que o usuário interaja com aquele mundo.Com o progresso recente feito nos dispositivos de renderização, como criação de monitores montados na cabeça (HMD) e vídeo de RV (frequentemente chamado de vídeo em 360 graus), uma qualidade significativa de experiência pode ser oferecida. As aplicações de RV que incluem jogo, treinamento, educação, vídeos esportivos, compras online, entretenimento e assim por diante.
[0042] Um típico sistema de RV inclui os componentes e etapas a seguir:
• Um conjunto de câmeras, que inclui tipicamente múltiplas câmeras individuais que apontam em direções diferentes que podem cobrir coletivamente todos os pontos de visualização ao redor do conjunto de câmeras.
• Costura de imagens, em que imagens de vídeo tiradas pelas múltiplas câmeras individuais são sincronizadas no domínio de tempo e costuradas no domínio de espaço para formar um vídeo esférico, mas mapeado para um formato retangular, como equirretangular (como um mapa do mundo) ou mapa de cubo.
• O vídeo no formato retangular mapeado é codificado/comprimido com o uso de um codec de vídeo, por exemplo, H.265/HEVC ou H.264/AVC.
• A transmissão contínua de bits (transmissões contínuas de bits) de vídeo comprimido pode ser armazenada e/ou encapsulada em um formato de mídia e transmitido (possivelmente apenas o subconjunto que cobre apenas a área que é vista por um usuário) através de uma rede para um
Petição 870190063436, de 08/07/2019, pág. 22/102
18/78 dispositivo receptor (isto é, um dispositivo de cliente).
• 0 dispositivo receptor recebe a transmissão continua (transmissões continuas) de bits de video, ou parte do mesmo, possivelmente encapsulado em um formato, e envia o sinal de video decodificado ou parte do mesmo para um dispositivo de renderização (que pode formar parte do mesmo dispositivo ou um dispositivo separado).
• 0 dispositivo de renderização pode ser, por exemplo, um monitor montado na cabeça (HMD), que pode rastrear o movimento de cabeça e pode ainda rastrear o movimento de olho, e renderizar a parte correspondente do video de modo que uma experiência imersiva seja entregue ao usuário.
[0043] No momento da escrita deste documento, o Formato de Aplicação de Midia Omnidirecional (OMAF) está sendo desenvolvido por MPEG para definir uma aplicação de midia gue possibilita aplicações de midia omnidirecional, com foco em aplicações de RV com video em 360 graus e áudio associado. O OMAF especifica uma lista de métodos de projeção que podem ser usados para conversão de um video esférico ou em 360 graus em um video retangular bidimensional, seguido por como armazenar midia omnidirecional e os metadados associados com o uso de formato de arquivo de midia de base ISO (ISOBMFF), e como encapsular, sinalizar e transmitir continuamente midia omnidirecional media com o uso de Transmissão Continua Adaptativa Dinâmica por HTTP (DASH), e finalmente quais codecs de video e de áudio assim como configurações de codificação de midia podem ser usados para compressão e
Petição 870190063436, de 08/07/2019, pág. 23/102
19/78
reprodução do sinal midia omnidirecional. 0 OMAF é
planejado para se tornar ISO/IEC 23000-20 e sua
especificação preliminar está disponível junto a
wgll.sc2 9.org/doc_end_usuário/documents/116_Chengdu/wgll/wl 643 9. zip .
[0044] Há casos de uso desejável de transmissão continua de dados de midia que envolvem geração, sinalização e uso de informações indicando regiões de interesse ou regiões de maior interesse. Na contribuição m37819 de MPEG, um caso de uso foi discutido sobre sinalização e uso de informações de corte de um diretor, de modo que a reprodução de RV possa incluir exibição de um visor que se altera dinamicamente que um diretor quer que o público foque, até mesmo quando o usuário não está girando sua cabeça ou alterando a visor através de outras interfaces de usuário (UI) . Tais janelas de visualização podem ser fornecidas com uma cena de video omnidirecional por cena.
[0045] O Pedido n° US 15/589.782, depositado em 8 de maio de 2017, publicado como Publicação de Patente n° US 2017/0339415, que é incorporado em sua totalidade a titulo de referência no presente documento, descreve técnicas para geração de informações nas regiões de maior interesse das estatísticas de usuário por um provedor de serviço ou de conteúdo, por exemplo, através das estatísticas das quais regiões foram solicitadas/vistas pela maioria dos usuários quando o conteúdo de video de RV foi fornecido através de um serviço de transmissão continua, em que uma região de maior interesse em uma
Petição 870190063436, de 08/07/2019, pág. 24/102
20/78 imagem de video de RV é uma das regiões que é provável e estatisticamente renderizada para o usuário no momento de apresentação da imagem. São reveladas também no Pedido Provisório No. 63/339,009 as técnicas para uso das informações nas regiões de maior interesse para propósitos de aprimoramento de desempenho de RV, como pré-busca de dados em transmissão continua adaptativa de RV por servidores de borda ou clientes, otimização de transcodificação quando um video de RV é transcodifiçado, por exemplo, para um codec ou mapeamento de projeção diferentes, gerenciamento de cache por um servidor de borda ou cache, e gerenciamento de conteúdo por um servidor de transmissão continua de video de RV. A sinalização de regiões de maior interesse foi revelada também, por exemplo, pelo uso de mensagens de SEI em uma transmissão continua de bits de video, de um grupo de amostra de formato de arquivo em um arquivo de midia, ou de elementos ou atributos de DASH de descrição de apresentação de midia (MPD) com o uso de grupo de amostra.
[0046] O Pedido n° US 14/491,805, depositado em 24 de maio de 2016, publicado como Publicação de Patente n° US 2017/0344843, que é incorporado em sua totalidade a titulo de referência no presente documento, descreve vários métodos para sinalização avançada de uma ou mais regiões de maior interesse no video de RV, incluindo entre outros a seguir:
• Um grupo de amostra que, quando incluido em uma caixa de fragmento de faixa, pode documentar informações de amostras que são fragmentos de faixa subsequente seguindo
Petição 870190063436, de 08/07/2019, pág. 25/102
21/78 aqueles que contêm o grupo de amostra (o SampleToGroupBox do tipo de grupamento e a caixa de descrição de grupo de amostra correspondente) na faixa.
• Exemplos do grupo de amostra mencionados acima.
• Sinalização de regiões de maior interesse diretamente com o uso de ID de bloco conforme especificado em HEVC, ID de grupo conforme definido em ISO/IEC 14496-15, ID de faixa conforme definido em ISO/IEC 14496-12 ou ID de representação de DASH conforme definido em ISO/IEC 23009-1.
[0047] Uma região de interesse (ROI) em video de RV/360 pode ser definida de pelo menos duas formas. A primeira forma exemplificativa consiste em definir a mesma com base em um sistema de coordenada de esfera, por exemplo, pela definição de uma região sobre a superfície esférica do video em 360. A segunda forma exemplificativa consiste em definir uma ROI com base no sistema de coordenada Cartesiano 2D em uma imagem 2D. A última é o que é usado nos Pedidos Provisórios n° US 62/339.009 e n° US 62/341.017 mencionados acima.
[0048] O documento de saida MPEG N 16440 menciona vários métodos para definir regiões de interesse com base no sistema de coordenada de esfera. Especificamente, esses métodos especificam uma região em uma superfície esférica que é abrangida pelos quatro segmentos de quatro circulos grandes ou de dois circulos pequenos, cada segmento entre dois pontos na superfície esférica. No presente documento, um circulo, um circulo grande e um circulo pequeno são definidos conforme a seguir:
Petição 870190063436, de 08/07/2019, pág. 26/102
22/78
A interseção de um plano e de uma esfera é um circulo (exceto quando a interseção é um ponto).
Todos os pontos desse circulo pertencem à superfície da esfera. Um circulo grande, também conhecido como uma ortodromia ou circulo de Riemannian, de uma esfera é a interseção da esfera e de um plana que passa pelo ponto central da esfera. 0 centro da esfera e o centro de um circulo grande estão colocalizados sempre. Qualquer outra interseção de um plano e de uma esfera que não atenda a essa condição e que não seja um ponto, é um circulo pequeno.
[0049] Quando um video de RV/360 é tocado de volta em um monitor montado na cabeça (HMD) ou em um monitor sem HMD como uma TV, um visor para o usuário. Tipicamente, um visor é uma região retangular em um plano que é tangente a uma esfera (isto é, cruza com a esfera em um ponto), em que o plano de visor plane é ortogonal à direção da visualização de usuário. Um visor pode ser gerado por aplicação da projeção retilinea, por exemplo, conforme discutido em J. Boyce, E. Alshina, A. Abbas, Y. Ye, JVET common test conditions and evaluation procedures for 360° video, Joint Video Exploration Team of ITU-T SG16WP3 and ISO/IEC JTC1/SC29/WG11, JVET-D1030, 4th
Meeting, out 2016.
[0050] A região na esfera que corresponde a um visor é a região que é abrangida pelos quatro segmentos de quatro circulos grandes.
[0051] Outras técnicas para sinalização dupla
Petição 870190063436, de 08/07/2019, pág. 27/102
23/78 de uma ou mais regiões de maior interesse no video de RV inclui sinalização de uma região com base em uma região na superfície periférica, e outra região com base em uma região na imagem decodificada.
[0052] As técnicas desta revelação podem ser aplicadas para abordar certos problemas que podem surgir em relação de regiões de interesse, por exemplo, em técnicas de transmissão contínua de mídia e/ou de RV. A mensagem de SAND de AnticipatedRequests pode ser usada por um cliente de DASH para anunciar para um DANE qual conjunto específico de segmentos está interessado, e para sinalizar o conjunto de segmentos em representações que o cliente de DASH provavelmente logo seleciona e solicita. Essa mensagem de SAND é adequada em cenários em que o cliente de DASH está participando de uma sessão de transmissão contínua de DASH e tem uma boa estimativa de quais segmentos são prováveis de necessitar de serem renderizados para o usuário com base na situação e tempo real dos comportamentos de cliente e de usuário além de outras informações relacionadas disponíveis para o cliente.
[0053] As informações sobre as quais regiões em um vídeo de RV que compreende o corte do diretor ou regiões de maior interesse, conforme indicado através de análise de estatísticas, podem se aplicar a todo um conteúdo de vídeo de RV. Tais informações podem ser usadas pelo cliente de DASH, além da situação em tempo real dos comportamentos de cliente e usuário, para determinar quais segmentos devem ser incluídos em uma mensagem de SAND de AnticipatedRequests durante uma sessão de transmissão
Petição 870190063436, de 08/07/2019, pág. 28/102
24/78 contínua de DASH. Tais informações, se presentes como metadados de formato de arquivo, podem ser acessadas diretamente pelo cliente de DASH. Entretanto, isso exige que o cliente de DASH analise metadados de formato de arquivo além da MPD, e pode exigir também que o cliente de DASH aplique um processo geométrico para a projeção e o empacotamento no sentido da região usado para geração das imagens antes de codificar para vídeo de RV.
[0054] Além disso, as informações acima (cujas regiões em um vídeo de RV compreendem o corte do diretor ou outras regiões de maior interesse por estatísticas) podem ser usadas também por um DANE (o servidor e/ou um cache original ou um elemento de CDN) para pré-buscar todos os Segmentos das Representações de DASH que compreendem o corte do diretor ou regiões de maior interesse. Devido à sua natureza em tempo real e sendo uma mensagem de situação originada apenas a partir do cliente de DASH, a mensagem de SAND de AnticipatedRequests não é adequada para comunicação como informações para DANEs.
[0055] Ainda um outro problema associado com projetos convencionais para comunicar o corte do diretor ou regiões de maior interesse para DANEs é que podem ser níveis diferentes de interesse ou probabilidades das regiões de interesse.
[0056] Ainda um outro problema com o uso das solicitações antecipadas é que os dispositivos de cliente precisam suportar SAND. Entretanto, muitos dispositivos de cliente não suportam SAND. Além disso, as solicitações antecipadas apenas abordam tipicamente dependências a curto
Petição 870190063436, de 08/07/2019, pág. 29/102
25/78 prazo para um único cliente, possivelmente até mesmo criando um estado do cliente com o MANE ou DANE.
[0057] Adicionalmente, podem ser níveis diferentes de interesse ou taxas de uso para conteúdos diferentes em nível de conteúdo. Por exemplo, alguns filmes ou títulos são mais consumidos pelos usuários que outros. O projeto de DASH atual não fornece sinalização de tais informações, que podem ser usadas também para pré-buscar a maioria dos conteúdos consumidos.
[0058] A Figura 1 é um diagrama de bloco que ilustra um sistema exemplificativo 10 que implementa técnicas para transmissão contínua de dados de mídia sobre uma rede. Nesse exemplo, o sistema 10 inclui o dispositivo de preparação de conteúdo 20, o dispositivo de servidor 60, elemento de rede de reconhecimento de mídia (MANE) 76 e o dispositivo de cliente 40. O dispositivo de cliente 40, o MANE 7 6, o dispositivo de preparação de conteúdo 20 e o dispositivo de servidor 60 são acoplados comunicativamente pela rede 74, que pode compreender a Internet. Em alguns exemplos, o dispositivo de preparação de conteúdo 20 e o dispositivo de servidor 60 podem compreender o mesmo dispositivo.
[0059] O dispositivo de preparação de conteúdo 20, no exemplo da Figura 1, compreende a fonte de áudio 22 e a fonte de vídeo 24. A fonte de áudio 22 pode compreender, por exemplo, um microfone que produz sinais elétricos representativos de dados de áudio capturados a serem codificados pelo codificador de áudio 26. Alternativamente, a fonte de áudio 22 pode compreender um
Petição 870190063436, de 08/07/2019, pág. 30/102
26/78 meio de armazenamento que armazena dados de áudio previamente registrados, um gerador de dados de áudio, como um sintetizador computadorizado, ou uma outra fonte de dados de áudio. A fonte de video 2 4 pode compreender uma câmera de video que produz dados de video a serem codificados pelo codificador de video 28, um meio de armazenamento codificado com dados de video previamente registrados, uma unidade de geração de dados de video, como uma fonte gráfica de computador, ou qualquer outra fonte de dados de video. 0 dispositivo de preparação de conteúdo 20 não é necessariamente acoplada comunicativamente ao dispositivo de servidor 60 em todos os exemplos, mas pode armazenar conteúdo de multimídia para um meio separado que é lido pelo dispositivo de servidor 60.
[0060] Os dados de áudio e vídeo brutos podem compreender dados analógicos e 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 falante enquanto o participante falante está falando, e a fonte de vídeo 24 pode obter simultaneamente dados de vídeo do participante que fala. Em outros exemplos, a fonte de áudio 22 pode compreender um meio de armazenamento legível por computador que compreende dados de áudio armazenados, e a fonte de vídeo 24 pode compreender um meio de armazenamento legível por computador que compreende dados de vídeo armazenados. Dessa maneira, as técnicas descritas nesta revelação podem ser aplicadas aos dados de áudio e vídeo em tempo real, em transmissão
Petição 870190063436, de 08/07/2019, pág. 31/102
27/78 contínua e ao vivo ou aos dados de áudio e vídeo préregistrados e arquivados.
[0061] Os quadros de áudio que correspondem aos quadros de vídeo são, em geral, quadros de áudio que contém dados de áudio que foram capturados (ou gerados) pela fonte de áudio 22 contemporaneamente com os dados de vídeo capturados (ou gerados) pela fonte de vídeo 24 que está contida nos quadros de vídeo. Por exemplo, enquanto um participante falante produz, em geral, dados de áudio pela fala, a fonte de áudio 22 captura os dados de áudio e a fonte de vídeo 24 captura dados de vídeo do participante falante ao mesmo tempo, ou seja, enquanto a fonte de áudio 22 está capturando os dados de áudio. Por conseguinte, um quadro de vídeo pode corresponder temporariamente a um ou mais quadros de vídeo particulares. Consequentemente, um quadro de áudio correspondente a um quadro de vídeo corresponde, em geral, a uma situação na qual os dados de áudio e os 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.
[0062] Em alguns exemplos, o codificador de áudio 2 6 pode codificar um carimbo de dados/hora em cada quadro de áudio codificado que representa um tempo no qual os dados de áudio para o quadro de áudio codificado foram registrados e, similarmente, o codificador de vídeo 28 pode codificar um carimbo de dados/hora em cada quadro de vídeo codificado que representa um tempo no qual os dados de vídeo para o quadro de vídeo codificado foram registrados.
Petição 870190063436, de 08/07/2019, pág. 32/102
28/78
Em tais exemplos, um quadro de áudio correspondente a um quadro de video pode compreender um quadro de áudio que compreende um carimbo de dados/hora e um quadro de video que compreende o mesmo carimbo de dados/hora. 0 dispositivo de preparação de conteúdo 20 pode incluir um relógio interno a partir do qual o codificador de áudio 2 6 e/ou codificador de video 28 pode gerar os carimbos de dados/hora, ou que a fonte de áudio 22 e a fonte de video 24 pode usar para associar dados de áudio e video, respectivamente, com um carimbo de dados/hora.
[0063] Em alguns exemplos, a fonte de áudio 22 pode enviar dados para o codificador de áudio 26 correspondente a um tempo no qual os dados de áudio foram registrados e a fonte de video 24 pode enviar dados para o codificador de video 28 correspondente a um tempo no qual os dados de video foram registrados. Em alguns exemplos, o codificador de áudio 26 pode codificar um identificador de sequência nos dados de áudio codificados para indicar ordenação temporal de dados de áudio codificados, mas sem indicar necessariamente um tempo absoluto no qual os dados de áudio foram registrados e, similarmente, o codificador de video 28 pode usar também identificadores de sequência para indicar uma ordenação temporal relativa de dados de video codificados. Similarmente, em alguns exemplos, um identificador de sequência pode ser mapeado ou, de outro modo, correlacionado com um carimbo de dados/hora.
[0064] O codificador de áudio 26 produz, em geral, uma transmissão continua de dados de áudio codificados, enquanto o codificador de video 28 produz uma
Petição 870190063436, de 08/07/2019, pág. 33/102
29/78 transmissão continua de dados de video codificados. Cada transmissão continua individual de dados (áudio ou video) pode ser chamado de uma transmissão continua elementar, uma transmissão continua elementar é um componente de uma representação digitalmente codificado e único (possivelmente comprimido). Por exemplo, a parte de áudio ou video codificada da representação pode ser uma transmissão continua elementar, uma transmissão continua elementar pode ser convertida em transmissão continua elementar empacotada (PES) antes de ser encapsulado dentro um arquivo de video. Dentro da mesma representação, um ID de transmissão continua pode ser usado para distinguir os pacotes de PES que pertencem a uma transmissão continua elementar de outros. A unidade básica de dados de uma transmissão continua elementar é um pacote de transmissão continua elementar empacotada (PES). Assim, dados de video codificados correspondem, em geral, às transmissões continuas de video elementares. Similarmente, dados de áudio correspondem a um ou mais transmissão continua elementares respectivos.
[0065] Muitos padrões de codificação de video, como ITU-T H.264/AVC e o padrão de Codificação de Video de Alta Eficiência (HEVC), definem a sintaxe, a semântica e o processo de decodificação para transmissões continuas de bits livres de erro, qualquer um dos quais conformados com um certo perfil ou nivel. Os padrões de codificação de video não especificam tipicamente o codificador, mas o codificador é encarregado de garantir que as transmissões continuas de bits geradas estejam em conformidade com o
Petição 870190063436, de 08/07/2019, pág. 34/102
30/78 padrão. No contexto de padrões de codificação de video, um perfil corresponde a um subconjunto de algoritmos, recursos ou ferramentas e restrições que se aplicam ao mesmo. Conforme definido pelo padrão H.264, por exemplo, um perfil é um subconjunto de toda a sintaxe de transmissão continua de bits que é especificado pelo padrão H.264. Um nível corresponde às limitações do consumo de recurso de decodificador, como, por exemplo, memória e computação de decodificador, que são relacionadas à resolução das imagens, taxa de bits e taxa de processamento de bloco. Um perfil pode ser sinalizado com um valor ide de perfil (indicador de perfil), enquanto um nível pode ser sinalizado com um valor ide de nível (indicador de nível) .
[0066] O padrão 264 reconhece que, por exemplo, dentro dos limites impostos pela sintaxe de um determinado perfil, ainda é possível exigir uma grande variação no desempenho de decodificadores e decodificadores dependendo dos valores tomados por elementos de sintaxe na transmissão contínua de bits, como o tamanho especificado das imagens decodificadas. O padrão H.264 reconhece adicionalmente que, em muitas aplicações, não é prático nem econômico implantar um decodificador capaz de lidar com todos os usos hipotéticos da sintaxe dentro de um perfil particular. Consequentemente, o padrão H.264 define um nível conforme um conjunto especificado de restrições imposto nos valores dos elementos de sintaxe na transmissão contínua de bits. Essas restrições podem ser limites simples nos valores. Alternativamente, essas restrições podem tomar a forma de combinações de restrições e
Petição 870190063436, de 08/07/2019, pág. 35/102
31/78 aritméticas de valores (por exemplo, largura de imagem multiplicada pela altura de imagem multiplicada pelo número de imagens decodificadas por segundo). 0 padrão H.264 proporciona adicionalmente que as implementações individuais possam suportar um nível diferente para cada perfil suportado.
[0067] Um decodificador em conformidade com um perfil suporta normalmente todos os recursos definidos no perfil. Por exemplo, como um recurso de codificação, a codificação da imagem B não é suportada no perfil de linha de base de H.264/AVC, mas é suportada em outros perfis de H.264/AVC. Um decodificador em conformidade com um nível deve ser capaz de decodificar qualquer transmissão contínua de bits que não exige recursos além das limitações definidas no nível. As definições de perfis e níveis podem ser úteis para interpretabilidade. Por exemplo, durante a transmissão de vídeo, um par de definições de perfil e nível pode ser negociado ou acordado para toda uma sessão de transmissão. Mais especificamente, no H.264/ AVC, um nível pode definir limitações no número de macroblocos que precisam ser processados, no tamanho de memória principal de imagem decodificada (DPB), no tamanho de memória principal de imagem codificada (CPB), na faixa de vetor de movimento vertical, no número máximo de vetores de movimento por dois MBs consecutivos e se um bloco B pode ter partições de submacrobloco inferiores a 8x8 pixels. Dessa maneira, um decodificador pode determinar se o decodificador é capaz de decodificar apropriadamente a transmissão contínua de bits.
Petição 870190063436, de 08/07/2019, pág. 36/102
32/78 [0068] No exemplo da Figura 1, a unidade encapsulamento 30 do dispositivo de preparação de conteúdo 20 recebe transmissões continuas elementares que compreende dados de video codificados do codificador de video 28 e transmissões continuas elementares que compreendem dados de áudio codificados do codificador de áudio 26. Em alguns exemplos, o codificador de video 28 e o codificador de áudio 26 podem, cada um, incluir empacotadores para formar pacotes de PES a partir de dados codificados. Em outros exemplos, o codificador de video 28 e o codificador de áudio 2 6 podem, cada um, se interligar com respectivos empacotadores para formar pacotes de PES a partir de dados codificados. Ainda em outros exemplos, a unidade de encapsulamento 30 pode incluir empacotadores para formar pacotes de PES a partir de dados de áudio e video codificados.
[0069] O codificador de video 28 pode codificar dados de video de conteúdo multimídia de uma variedade de formas para produzir representações diferentes do conteúdo multimídia em várias taxas de bits e com várias características, como resoluções de pixel, taxas de quadro, conformidade com vários padrões de codificação, conformidade com vários perfis e/ou niveis de perfis para vários padrões de codificação, representações que têm uma ou múltiplas visualizações (por exemplo, para reprodução bidimensional ou tridimensional) ou outras tais características. Uma representação, conforme usado nesta revelação, pode compreender um dos dados de áudio, dados de video, dados de texto (por exemplo, para legendas ocultas)
Petição 870190063436, de 08/07/2019, pág. 37/102
33/78 ou outros dados. A representação pode incluir uma transmissão continua elementar, como uma transmissão continua elementar de áudio ou uma transmissão continua elementar de video. Cada pacote de PES pode incluir um id de transmissão continua que identifica a transmissão continua elementar ao qual o pacote de PES pertence. A unidade de encapsulamento 30 é responsável pela montagem de transmissões continuas elementares nos arquivos de video (por exemplo, segmentos) de várias representações.
[0070] A unidade de encapsulamento 30 recebe pacotes de PES para transmissões continuas elementares de uma representação do codificador de áudio 2 6 e do codificador de video 28 e forma unidades de camada de abstração de rede correspondente (NAL) a partir de pacotes de PES. Os segmentos de video codificados podem ser organizados em unidades de NAL, que fornecem uma representação de video de rede amigável que aborda aplicações, como telefonia de video, armazenamento, difusão ou transmissão continua. As unidades de NAL podem ser categorizadas em unidades de NAL com Camada de Codificação de Video (VCL) e unidades de NAL sem VCL. AS unidades de VCL podem conter o motor de compressão principal e pode incluir dados em nivel de bloco, macrobloco e/ou fatia. Outras unidades de NAL podem ser unidades de NAL sem VCL. Em alguns exemplos, uma imagem codificada em uma instância de tempo, apresentada normalmente como uma imagem primária codificada, pode estar contida em uma unidade acesso, que pode incluir uma ou mais unidades de NAL.
[0071] As unidades de NAL sem VCL podem
Petição 870190063436, de 08/07/2019, pág. 38/102
34/78 incluir unidades de NAL de conjunto de parâmetros e unidades de NAL de SEI, entre outras. Os conjuntos de parâmetros podem conter informações de cabeçalho em nivel de sequência (em conjuntos de parâmetro de sequência (SPS)) e as informações de cabeçalho em nivel de imagem que se alteram raramente (em conjuntos de parâmetro de imagem (PPS)). Com os conjuntos de parâmetro (por exemplo, PPS e SPS), as informações que se alteram raramente não precisam ser repetidas para cada sequência ou imagem, por conseguinte, a eficiência de codificação pode ser aprimorada. Adicionalmente, o uso de conjuntos de parâmetro pode possibilitar transmissão fora de banda das informações de cabeçalho importantes, evitando a necessidade de transmissões redundantes para resiliência de erro. Em exemplos de transmissão fora de banda, as unidades de NAL de conjunto de parâmetros podem ser transmitidas em um canal diferente de outras unidades de NAL, como unidades de NAL de SEI.
[0072] As Informações Suplementares de Melhoramento (SEI) podem conter informações que não são necessárias para decodificar as amostras de imagens codificadas das unidades de NAL com VCL, mas podem assistir em processos relacionados à decodificação, à exibição, à resiliência de erro e outros propósitos. As mensagens de SEI podem estar contidas em unidades de NAL sem VCL. As mensagens de SEI são a parte normativa de algumas especificações de padrão e, assim, não são sempre obrigatórias para implementação de decodificador compatível com o padrão. As mensagens de SEI podem ser mensagens de
Petição 870190063436, de 08/07/2019, pág. 39/102
35/78
SEI em nível de sequência ou mensagens de SEI em nível de imagem. Algumas informações em nível de sequência podem estar contidas em mensagens de SEI, como mensagens de SEI de informações de escalabilidade no exemplo de SVC e mensagens de SEI de informações de escalabilidade de visualização em MVC. Essas mensagens de SEI exemplificativas podem transmitir informações, por exemplo, na extração de pontos e características de operação 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 características das representações. A unidade de encapsulamento 30 pode formatar o MPD de acordo com de acordo com linguagem extensível de marcação genérica (XML).
[0073] A unidade de encapsulamento 30 pode fornecer dados para uma ou mais representações de conteúdo multimídia ao longo do arquivo de manifesto (por exemplo, a MPD) para emitir a interface 32. A interface de saída 32 pode compreender uma interface de rede ou uma interface para gravar em um meio de armazenamento, como uma interface de barramento serial universal (USB), um gravador (burner) de CD ou DVD, uma interface para a mídia de armazenamento magnético ou flash ou outras interfaces para armazenar ou transmitir dados de mídia. A unidade de encapsulamento 30 pode fornecer dados para cada uma das representações de conteúdo multimídia para emitir a interface 32, que pode enviar os dados para o dispositivo de servidor 60 através da mídia de transmissão de rede ou de armazenamento. No exemplo da Figura 1, o dispositivo de servidor 60 inclui o
Petição 870190063436, de 08/07/2019, pág. 40/102
36/78 meio de armazenamento 62 que armazena vários conteúdos multimidia 64, cada um incluindo um respectivo arquivo de manifesto 66 e uma ou mais representações 68A a 68N (representações 68) . Em alguns exemplos, a interface de saida 32 pode ser enviada também diretamente para a rede 74 .
[0074] 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 caracteristicas, como codec, perfil e nivel, resolução, número de visualizações, formato de arquivo para segmentos, informações do tipo de texto que pode identificar um idioma ou outras caracteristicas de texto a ser exibido 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 de câmera ou um perspectiva de câmera de mundo real de uma cena para representações no conjunto de adaptações, informações de classificação que descrevem a adequabilidade de conteúdo para o público particular ou similares.
[0075] O arquivo de manifesto 66 pode incluir dados indicativos dos subconjuntos de representações 68 correspondentes aos conjuntos de adaptação particulares, assim como às caracteristicas comuns para os conjuntos de adaptação. O arquivo de manifesto 66 pode incluir também dados representativos de caracteristicas individuais, como taxas de bits, para representações de conjuntos de adaptação individuais. Dessa maneira, um conjunto de
Petição 870190063436, de 08/07/2019, pág. 41/102
37/78 adaptações pode fornecer uma adaptação de largura de banda de rede simplificada. As representações em um conjunto de adaptações podem ser indicadas com o uso de subelementos filho de um elemento de conjunto de adaptações do arquivo de manifesto 66.
[0076] O dispositivo de servidor 60 inclui a unidade de processamento de solicitação 70 e a interface de rede 72. Em alguns exemplos, o dispositivo de servidor 60 pode incluir uma pluralidade de interfaces de rede. Adicionalmente, qualquer um ou todos os recursos do dispositivo de servidor 60 pode ser implementado em outros dispositivos de uma rede de entrega de conteúdo, como roteadores, pontes, dispositivos proxy, comutadores ou outros dispositivos. Em alguns exemplos, dispositivos intermediários de uma rede de entrega de conteúdo podem transferir por cache dados de conteúdo multimídia 64, e incluir componentes que se conformam com aqueles do dispositivo de servidor 60. Em geral, a interface de rede 72 é configurada para enviar e receber dados através da rede 7 4.
[0077] A unidade de processamento de solicitação 70 é configurada para receber solicitações de rede dos dispositivos de cliente, como dispositivo de cliente 40, para dados do meio de armazenamento 62. Por exemplo, a unidade de processamento de solicitação 70 pode implantar a versão 1.1 de protocolo de transferência de hipertexto (HTTP), conforme descrito em RFC 2616, Hypertext Transfer Protocol - HTTP/1.1, de R. Fielding et al, Network Working Group, IETF, Junho 1999. Ou seja, a
Petição 870190063436, de 08/07/2019, pág. 42/102
38/78 unidade de processamento de solicitação 70 pode ser configurada para receber solicitações de GET ou de GET parcial de HTTP e para fornecer dados do conteúdo multimidia 64 em resposta às solicitações. As solicitações podem especificar um segmento de uma das representações 68, por exemplo, com o uso de um URL do segmento. Em alguns exemplos, as solicitações podem especificar também uma ou mais faixa de bytes do segmento, comprimindo, assim, as solicitações de GET. A unidade de processamento de solicitação 70 pode ser configurada adicionalmente para solicitações de 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 de solicitação 70 pode ser configurada para processar as solicitações para fornecer os dados solicitados para um dispositivo que solicita, como dispositivo de cliente 40.
[0078] Adicional ou alternativamente, a unidade de processamento de solicitação 70 pode ser configurada para entregar dados de midia através de um protocolo de difusão ou de difusão múltipla, como eMBMS. O dispositivo de preparação de conteúdo 20 pode criar segmentos e/ou subsegmentos de DASH substancialmente da mesma forma conforme descrito, mas o dispositivo de servidor 60 pode entregar esses segmentos ou subsegmentos com o uso de eMBMS ou um outro protocolo de transporte de rede de difusão ou de difusão múltipla. Por exemplo, a unidade de processamento de solicitação 70 pode ser configurada para receber uma solicitação de junção de grupo de difusão múltipla do dispositivo de cliente 40. Ou seja,
Petição 870190063436, de 08/07/2019, pág. 43/102
39/78 o dispositivo de servidor 60 pode divulgar um endereço de protocolo de Internet (IP) associado a um grupo de difusão múltipla para dispositivos de cliente, incluindo o dispositivo de cliente 40, associados com conteúdo de midia particular (por exemplo, uma difusão de evento ao vivo). O dispositivo de cliente 40, por sua vez, pode encaminhar uma solicitação para juntar o grupo de difusão múltipla. Essa solicitação pode ser propagada através da rede 74, por exemplo, de roteadores que constituem a rede 74, de modo que os roteadores sejam direcionados ao tráfego destinado para o endereço de IP associado com o grupo de difusão múltipla para subscrever dispositivos de cliente, como dispositivo de cliente 40.
[0079] Conforme ilustrado no exemplo da Figura 1, o conteúdo multimidia 64 inclui o arquivo de manifesto 66, que pode corresponder a uma descrição de apresentação de midia (MPD) . O arquivo de manifesto 66 pode conter
descrições de representações 68 alternativas diferentes
(por exemplo, os serviços de video com qualidades
diferentes) e a descrição pode incluir, por exemplo,
informações de codec, um valor de perfil, um valor de
nivel, uma taxa de bits e outras características
descritivas das representações 68 . 0 dispositivo de cliente
pode recuperar a MPD de uma apresentação de midia para determinar como acessar segmentos das representações 68.
[0080] Em particular, a unidade de recuperação 52 pode recuperar dados de configuração (não mostrados) do dispositivo de cliente 40 para determinar capacidades de decodificação do decodificador de video 48 e capacidades de
Petição 870190063436, de 08/07/2019, pág. 44/102
40/78 renderização da saída de vídeo 44. Os dados de configuração podem incluir também qualquer uma ou toda a preferência de idioma selecionada por um usuário do dispositivo de cliente 40, uma ou mais perspectivas de câmera correspondentes às preferências de profundidade definidas pelo usuário do dispositivo de cliente 40 e/ou à preferência de classificação selecionada pelo usuário do dispositivo de cliente 40. A unidade de recuperação 52 pode compreender, por exemplo, um navegador da web ou um cliente de mídia configurado para encaminhar solicitações de GET e de GET parcial de 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 de cliente 40. Em alguns exemplos, toda ou porções da funcionalidade descrita em relação à unidade de recuperação 52 pode ser implementada em hardware ou em uma combinação de hardware, software e/ou firmware, em que o hardware requerido pode ser fornecido para executar as instruções para software ou firmware.
[0081] A unidade de recuperação 52 pode comparar as capacidades de decodificação e de renderização do dispositivo de cliente 40 com as características das representações 68 indicadas pelas informações do arquivo de manifesto 66. A unidade de recuperação 52 pode recuperar inicialmente pelo menos uma porção do arquivo de manifesto 66 para determinar características das 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
Petição 870190063436, de 08/07/2019, pág. 45/102
41/78 unidade de recuperação 52 pode selecionar um subconjunto das representações 68 (por exemplo, um conjunto de adaptações) que tem características que podem ser satisfeitas pelas capacidades de codificação e de renderização do dispositivo de cliente 40. A unidade de recuperação 52 pode, então, determinar taxas de bits para representações no conjunto de adaptações, determinar uma quantidade atualmente disponível de largura de banda de rede e recuperar segmentos a partir de uma das representações que têm uma taxa de bits que pode ser satisfeita pela largura de banda de rede.
[0082] Em geral, as representações de taxa de bits mais altas podem render uma reprodução de video de maior qualidade, enquanto as representações de taxa de bits menor podem fornecer uma reprodução de video de qualidade suficiente quando a largura de banda de rede disponível diminui. Consequentemente, quando a largura de banda de rede disponível é relativamente alta, a unidade de recuperação 52 pode recuperar dados a partir de representações de taxa de bits relativamente alta, enquanto, quando a largura de banda de rede disponível é baixa, a unidade de recuperação 52 pode recuperar dados a partir de representações de taxa de bits relativamente baixa. Dessa maneira, o dispositivo de cliente 40 pode transmitir continuamente múltiplos dados de midia sobre a rede 7 4 uma vez que se adapta também à disponibilidade de alteração de largura de banda de rede da rede 74.
[0083] Adicional ou alternativamente, a unidade de recuperação 52 pode ser configurada para receber
Petição 870190063436, de 08/07/2019, pág. 46/102
42/78 dados de acordo com um protocolo de rede de difusão ou de difusão múltipla, como eMBMS ou difusão múltipla de IP. Em tais exemplos, a unidade de recuperação 52 pode encaminhar uma solicitação para juntar um grupo de rede de difusão múltipla associado com conteúdo de midia particular. Após a junção do grupo de difusão múltipla, a unidade de recuperação 52 pode receber dados do grupo de difusão múltipla sem solicitações adicionais emitidas para o dispositivo de servidor 60 ou dispositivo de preparação de conteúdo 20. A unidade de recuperação 52 pode encaminhar uma solicitação para deixar o grupo de difusão múltipla quando os dados do grupo de difusão múltipla não forem mais necessários, por exemplo, para parar a reprodução ou para alterar canais para um grupo de difusão múltipla diferente.
[0084] 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 pode, por sua vez, fornecer os segmentos para a unidade de desencapsulamento 50. A unidade de desencapsulamento 50 pode desencapsular elementos de um arquivo de video em transmissões continuas de PES constituintes, desempacotar as transmissões continuas de PES para recuperar dados codificados e enviar os dados codificados para o decodificador de áudio 46 ou decodificador de video 48, dependendo se os dados codificados são parte de uma transmissão continua de áudio ou de video, por exemplo, conforme indicado pelos cabeçalhos de pacote de PES da transmissão continua. O decodificador de áudio 46 decodifica dados de áudio codificados e envia os dados de
Petição 870190063436, de 08/07/2019, pág. 47/102
43/78 áudio decodificados para a saida de áudio 42, enquanto o decodificador de video 48 decodifica dados de video codificados e envia os dados de video decodificados, que podem incluir uma pluralidade de visualizações de uma transmissão continua, para uma saida de video 44.
[0085] O codificador de video 28, o decodificador de video 48, o codificador de áudio 26, o decodificador de áudio 46, a unidade de encapsulamento 30, a unidade de recuperação 52 e a unidade de desencapsulamento 50 podem, cada um, ser implementados como qualquer um dentre uma variedade de conjunto de circuitos de processamento adequado, conforme aplicável, como conjunto de circuitos de processamento de função fixa e/ou programação, que pode incluir um ou mais microprocessadores, processadores de sinal digital (DSPs), circuitos integrados de aplicação especifica (ASICs) , matrizes de portas programáveis em campo (FPGAs), conjunto de circuitos lógicos discretos, software, hardware, firmware ou qualquer combinação dos mesmos. Cada um dentre o codificador de video 28 e o decodificador de video 48 pode ser incluido em um ou mais codificadores ou decodificadores, qualquer um dos quais pode ser integrado como parte de um codificador de video/decodificador combinados (CODEC). Do mesmo modo, cada um dentre o codificador de áudio 26 e o decodificador de áudio 46 pode ser incluido em um ou mais codificadores ou decodificadores, qualquer um dos quais pode ser integrado como parte de um CODEC combinado. Um aparelho que inclui o codificador de video 28, o decodificador de video 48, o
Petição 870190063436, de 08/07/2019, pág. 48/102
44/78 codificador de áudio 26, o decodificador de áudio 46, a unidade de encapsulamento 30, a unidade de recuperação 52 e/ou a unidade de desencapsulamento 50 pode compreender um circuito integrado, um microprocessador e/ou um dispositivo de comunicação sem fio, como um telefone celular.
[0086] O dispositivo de cliente 40, o dispositivo de servidor 60 e/ou o dispositivo de preparação de conteúdo 20 podem ser configurados para operar de acordo com as técnicas desta revelação. Para os propósitos de exemplo, esta revelação descreve essas técnicas em relação ao dispositivo de cliente 40 e ao dispositivo de servidor 60. Entretanto, deve ser entendido que o dispositivo de preparação de conteúdo 20 pode ser configurado para realizar essas técnicas, em vez (ou além de) do dispositivo de servidor 60.
[0087] A unidade de encapsulamento 30 pode formar unidades de NAL que compreendem um cabeçalho que identifica um programa ao qual a unidade de NAL pertence, assim como uma carga útil, por exemplo, dados de áudio, dados de vídeo ou dados que descrevem o transporte ou transmissão contínua de programa ao qual a unidade de NAL corresponde. Por exemplo, no H.264/AVC, uma unidade de NAL inclui um cabeçalho de 1-byte e uma carga útil de tamanho variado. Uma unidade de NAL que inclui 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 de 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
Petição 870190063436, de 08/07/2019, pág. 49/102
45/78 encapsulamento 30 pode receber dados de vídeo codificados do codificador de vídeo 28 sob forma de pacotes de PES de transmissões contínuas elementares. A unidade de encapsulamento 30 pode associar cada transmissão contínua elementar com um programa correspondente.
[0088] A unidade de encapsulamento 30 pode montar também unidades de acesso a partir de uma pluralidade de unidades de NAL. Em geral, uma unidade de acesso pode compreender uma ou mais unidades de NAL para representar um quadro de dados de vídeo, assim como dados de áudio correspondentes ao quadro quando os dados de áudio estão disponíveis. Uma unidade de acesso inclui, em geral, todas as unidades de NAL para uma instância de tempo de saída, todos os dados de áudio e vídeo para uma instância de tempo. Por exemplo, se cada visualização tem uma taxa de quadro de 20 quadros por segundo (fps), então, cada instância de tempo pode corresponder a um intervalo de tempo de 0,05 segundos. Durante esse intervalo de tempo, os quadros específicos de todas as visualizações da mesma unidade de acesso (a mesma instância de tempo) podem ser renderizados simultaneamente. Em um exemplo, uma unidade de acesso pode compreender uma imagem codificada em uma instância de tempo, que pode ser apresentada como uma imagem primária codificada.
[0089] Consequentemente, uma unidade de acesso pode compreender todos os quadros de áudio e vídeo de uma instância temporal comum, por exemplo, todas as visualizações correspondentes ao tempo X. Esta revelação se refere também a uma imagem codificada de uma visualização
Petição 870190063436, de 08/07/2019, pág. 50/102
46/78 particular como um componente de visualização. Ou seja, um componente de visualização pode compreender uma imagem codificada (ou quadro) para uma visualização particular em um tempo particular. Consequentemente, uma unidade de acesso pode ser definida como compreendendo todos os componentes de visualização de uma instância temporal comum. A ordem de decodificação de unidades de acesso não precise ser necessariamente a mesma que a ordem de saida ou exibição.
[0090] Uma apresentação de midia pode incluir uma descrição de apresentação de midia (MPD), que pode conter descrições de representações alternativas diferentes (por exemplo, serviços de video com diferentes qualidades) e a descrição pode incluir, por exemplo, informações de codec, um valor de perfil e um valor de nivel. Uma MPD é um exemplo de um arquivo de manifesto, como arquivo de manifesto 66. O dispositivo de cliente 40 pode recuperar a MPD de uma apresentação de midia para determinar como acessar fragmentos de filme de várias apresentações. Os fragmentos de filme podem estar localizados em caixas de fragmentos de filme (caixas de moof) de arquivos de video.
[0091] O arquivo de manifesto 66 (que pode compreender, por exemplo, uma MPD) pode divulgar disponibilidade de segmentos das representações 68. Ou seja, a MPD pode incluir informações que indicam o tempo de relógio de parede no qual um primeiro segmento de uma das representações 68 se torna disponível assim como informações que indicam as durações de segmentos contidos nas representações 68. Dessa maneira, a unidade de
Petição 870190063436, de 08/07/2019, pág. 51/102
47/78 recuperação 52 do dispositivo de 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 particular.
[0092] Após a unidade de encapsulamento 30 ter montado unidades de NAL e/ou unidades de acessos em um arquivo de vídeo com base nos dados recebidos, a unidade de encapsulamento 30 passa o arquivo de vídeo para a interface de saída 32 para saída. Em alguns exemplos, a unidade de encapsulamento 30 pode armazenar localmente o arquivo de vídeo ou enviar o arquivo de vídeo para um servidor remoto através da interface de saída 32, em vez de enviar diretamente o arquivo de vídeo para o dispositivo de cliente 40. A interface de saída 32 pode compreender, por exemplo, um transmissor, um transceptor, um dispositivo para gravação de dados em um meio legível por computador como, por exemplo, uma unidade ótica, uma unidade de mídia magnética (por exemplo, unidade de disquete) , uma porta de barramento serial universal (USB), uma interface de rede ou outras interface de saída. A interface de saída 32 emite o arquivo de vídeo para um meio legível por computador, como, por exemplo, um sinal de transmissão, um meio magnético, um meio ótico, uma memória, uma unidade de flash ou outro meio legível por computador.
[0093] A interface de rede 54 pode receber uma unidade de NAL ou unidade de acesso através da rede 7 4 e fornecer a unidade de NAL ou unidade de acesso para a unidade de desencapsulamento 50, através da unidade de recuperação 52. A unidade de desencapsulamento 50 pode
Petição 870190063436, de 08/07/2019, pág. 52/102
48/78 desencapsular elementos de um arquivo de video em transmissões continuas de PES constituintes, pode desempacotar transmissões continuas de PES para recuperar dados codificados pode enviar os dados codificados para o decodificador de áudio 46 ou decodificador de video 48, dependendo de se os dados codificados são parte de uma transmissão continua de áudio ou video, por exemplo, conforme indicado pelos cabeçalhos de pacote de PES da transmissão continua. 0 decodificador de áudio 46 decodifica dados codificados de áudio e envia os dados de áudio decodificados para a saida de áudio 42, enquanto o decodificador de video 48 decodifica dados de video codificados e envia os dados de video decodificados, que podem incluir uma pluralidade de visualizações de uma transmissão continua, para a saida de video 44.
[0094] De acordo com as técnicas desta revelação, um dispositivo de midia, como dispositivo de cliente 40, pode receber informações sinalizadas em que se esperam que as estruturas de dados (por exemplo, representações, conjuntos de adaptação, apresentação de midias, segmentos ou similares) sejam de maior interesse para usuários que outras. Os dados de midia são tipicamente chamados de conteúdo, mas a popularidade de conteúdo pode ser traduzida em estruturas de entrega de DASH gue são manuseadas facilmente por elementos de rede de HTTP, como dispositivo de servidor 60, dispositivo de cliente 40, dispositivo de preparação de conteúdo 20 e outros dispositivos (como MANEs ou DANEs). Se o provedor de conteúdo (por exemplo, dispositivo de preparação de
Petição 870190063436, de 08/07/2019, pág. 53/102
49/78 conteúdo 20 e/ou dispositivo de servidor 60) fornecer tais dados, tais informações podem ser usadas para pré-busca de dados pelo dispositivo de cliente 40 ou por elementos de rede intermediários contidos na rede 74 (não mostrados no exemplo da Figura 1) entre dispositivos de cliente e dispositivos de servidor original em sistemas de transmissão contínua adaptativa, como sistema 10. Tais informações podem ser usadas também, por exemplo, para entregar dados que são considerados mais relevantes em um enlace de dados preferencial, por exemplo, em difusão múltipla ou difusão, enquanto dados menos populares apenas podem ser fornecidos em difusão única a partir do servidor original (por exemplo, dispositivo de servidor 60). O dispositivo de cliente 40 ou um dispositivo de rede intermediário da rede 74 pode pré-buscar dados esperados para serem populares em maior qualidade, a fim de assegurar que tais dados estejam disponíveis em qualidade boa para muitos usuários. Uma ou mais dessas técnicas podem ser aplicadas independentemente ou em combinação com outras.
[0095] Em um exemplo, o dispositivo de servidor 60 fornece uma sinalização em nível de MPD no arquivo de manifesto 66 que indica consumo relativo em nível de conteúdo ou nível de arquivo de manifesto (por exemplo, nível de MPD) ou taxa de consumo ou solicitação relativa dentre os conteúdos diferentes do meio de armazenamento 62. Por exemplo, a indicação não pode ter unidade e um valor maior pode indicar uma verossimilhança ou probabilidade de uma Representação (por exemplo, uma das representações 68) ou um Conjunto de Adaptações da
Petição 870190063436, de 08/07/2019, pág. 54/102
50/78
Apresentação de Mídia ser consumida/solicitada. Essas informações podem ser usadas por DANEs para pré-buscar os títulos mais populares (por exemplo, mais pedidos) ou partes dos mesmos a serem preparados que seriam provavelmente logo solicitados por dispositivos de cliente, como dispositivo de cliente 40.
[00 96] Como um exemplo, o dispositivo de servidor 60 pode adicionar um @contentRequestRate de atributo adicional a um arquivo de manifesto 66 (por exemplo, uma MPD) , que pode ser atribuído em nível de Representação, de Conjunto de Adaptação e/ou de MPD. Quando presente, o valor desse atributo indica uma taxa de consumo ou solicitação relativa em nível de conteúdo ou em nível de MPD dentre conteúdos diferentes. O valor desse atributo pode ser sem unidade. Um valor maior pode indicar uma verossimilhança maior que a Representação, Conjunto de Adaptação ou Apresentação de Mídia será consumida/solicitada. Alternativamente, um valor menor pode indicar uma verossimilhança ou probabilidade maior dos dados serem consumidos/solicitados.
[0097] Assim, um MANE, um DANE ou o dispositivo de cliente 40 pode usar os valores desse atributo para determinar verossimilhanças relativas que, por exemplo, cada uma das representações 68 será consumida e para pré-buscar dados de mídia de uma das representações 68 que tem a verossimilhança/probabilidade mais alta de ser consumida/solicitada. Ou seja, o MANE/DANE/dispositivo de cliente 40 pode pré-buscar os dados de mídia correspondentes, em que o MANE/DANE/dispositivo de cliente
Petição 870190063436, de 08/07/2019, pág. 55/102
51/78 pode recuperar os dados de mídia sem uma solicitação explícita, por exemplo, de um usuário (ou no caso de um MANE/DANE, do dispositivo de cliente 40 ou de outros dispositivos de cliente).
[0098] Adicional ou alternativamente, o dispositivo de servidor 60 pode fornecer um Conjunto de Adaptação e/ou uma sinalização em nível de Representação (por exemplo, no arquivo de manifesto 66, como uma MPD) que indica a taxa de consumo ou solicitação relativa em partes de tempo/temporal de uma representação dentre todas as representações contidas na mesma Apresentação de Mídia (por exemplo, representações 68) . O dispositivo de cliente 40 e/ou um MANE/DANE pode usar essas informações para prébuscar as peças provavelmente mais solicitadas da Apresentação de Mídia a serem preparadas que provavelmente logo seriam solicitadas por alguns dispositivos de cliente, por exemplo, o dispositivo de cliente 40. Essas peças podem, por exemplo, cobrir uma representação de corte do diretor de um conteúdo de vídeo de RV/360.
[0099] Em um exemplo, o dispositivo de
servidor 60 pode sinalizar um elemento de RepRequestRate em
nível de Representação, que pode ser um elemento opcional
do arquivo de manifesto 66. Esse elemento pode compreender uma matriz de pares de dois atributos de {@repRequestRate, @validTimeEnd}, em que @repRequestRate pode indicar a taxa de consumo ou solicitação relativa contida na mesma Apresentação de Mídia (que pode ser novamente sem unidade, um valor maior pode significar verossimilhança maior de os (Subsegmentos)Segmentos contidos na duração de tempo como
Petição 870190063436, de 08/07/2019, pág. 56/102
52/78 especificada abaixo serem consumidos/solicitados) , e @validTimeEnd pode indicar o fim, na linha de tempo de midia, da duração de tempo dentro da qual @repRequestRate de valor de taxa de consumo ou solicitação relativa se aplica. 0 inicio da duração de tempo pode ser o começo do Periodo atual ou um tempo indicado por uma instância prévia de @validTimeEnd. Assim, o dispositivo de cliente 40 ou um MANE/DANE pode determinar e pré-buscar um ou mais segmentos dentro do tempo correspondente da representação correspondente que tem a probabilidade mais alta de ser solicitada/consumida.
[0100] Adicional ou alternativamente, o dispositivo de servidor 60 pode sinalizar as informações em nivel de Representação de taxa de consumo ou solicitação relativa da Representação dentre todas as Representações dentro da mesma Apresentação de Midia (por exemplo, representações 68) como um valor fixado para uma duração de tempo total da Representação, isto é, em partes de tempo/temporal. Assim, o dispositivo de cliente 40 (ou um MANE/DANE) pode determinar uma taxa de consumo ou solicitação relativa para uma representação individual de uma duração total da representação.
[0101] Adicional ou alternativamente, o dispositivo de servidor 60 pode sinalizar taxas de consumo ou solicitação relativas em um ou mais dentre um nivel de Periodo nivel, um nivel de Conjunto de Adaptação, um nivel de Representação e/ou um nivel de Sub-Representação. O dispositivo de cliente 40 pode ser configurado para determinar que um valor para uma sinalização de nivel
Petição 870190063436, de 08/07/2019, pág. 57/102
53/78 inferior, se o mesmo existir, sobregravar qualquer sinalização de nivel superior. Ou seja, os valores podem ser sinalizados em dois ou mais dentre um nivel de periodo de DASH, um nivel de conjunto de adaptações de DASH, um nivel de representação de DASH ou um nivel de subrepresentação de DASH e o cliente de DASH 40 pode determinar que os valores sinalizados em niveis inferiores substituam os valores sinalizados em niveis superiores. Alternativamente, um valor inferior pode indicar uma verossimilhança ou probabilidade maior de os dados serem consumidos/solicitados.
[0102] Adicional ou alternativamente, o dispositivo de servidor 60 pode sinalizar informações em nivel de metadados temporizados, em que o dispositivo de servidor 60 pode fornecer os metadados como uma faixa separada que pode ser entendida pelo dispositivo de cliente 40 ou por um MANE/DANE que faz uso dessas informações. A faixa de metadados pode ser multiplexada com certa faixa de midia na mesma Representação ou encapsulada exclusivamente na sua própria Representação.
[0103] Ainda conforme um outro exemplo, o dispositivo de servidor 60 pode sinalizar uma nova mensagem de PED que pode carregar a taxa de consumo ou solicitação relativa informações conforme descrito acima para uma Apresentação de Midia. O corpo da mensagem pode carregar apenas as informações de taxa de consumo ou solicitação relativa e um ID de MPD que identifica a MPD à qual as informações se aplicam, mas sem outras partes da MPD. Alternativamente, o corpo da mensagem de PED pode carregar
Petição 870190063436, de 08/07/2019, pág. 58/102
54/78 apenas a própria MPD, que contém as informações de taxa de consumo ou solicitação relativa assim como outras partes da MPD. A mensagem de PED que carrega apenas as informações de consumo relativo ou de busca de taxa pode ser usada quando todos os destinos têm acesso à MPD, enquanto a mensagem de PED que carrega a própria MPD pode ser usada quando pelo menos um dos destinos não tem acesso à MPD.
[0104] Por exemplo, para MANEs/DANEs que têm acesso à própria MPD, o dispositivo de servidor 60 pode elaborar a mensagem de PED para incluir informações para atualização de taxas de consumo ou solicitação relativas, e a mensagem pode incluir: um valor para @mpdld que identifica a MPD à qual essa mensagem se aplica; um valor para @contentRequestRate conforme discutido acima e valores para uma matriz de {@repld, RepRequestRate}, em que @repld é o ID de Representação, e RepRequestRate é um elemento com as mesmas sintaxe e semântica conforme discutido acima. Alternativamente, para MANEs/DANEs que não têm acesso à própria MPD, então, a mensagem de PED pode conter a própria MPD com as informações de taxa de consumo ou solicitação relativa atualizada.
[0105] Dessa maneira, o dispositivo de cliente 40 representa um exemplo de um dispositivo de mídia para recuperar dados de mídia, em que o dispositivo de mídia inclui um ou mais processadores configurados para receber informações que indicam pelo menos uma estrutura de dados de uma pluralidade de estruturas de dados é provável de ser de interesse de um usuário, em que a estrutura de dados inclui dados de mídia, e para recuperar os dados de mídia
Petição 870190063436, de 08/07/2019, pág. 59/102
55/78 da estrutura de dados antes de receber uma solicitação para os dados de midia do usuário. Nesse exemplo, o dispositivo de cliente 40 pode recuperar (ou seja, pré-buscar) os dados de midia a partir do dispositivo de servidor 60.
[0106] O MANE 76 representa, em geral, um dispositivo de midia que pode realizar pré-busca de dados de midia de acordo com as técnicas desta revelação. O MANE 76 pode incluir uma memória configurada para, por exemplo, armazenar dados de midia recuperados e um ou mais processadores implementados no conjunto de circuitos e configurados para realizar as técnicas desta revelação. Assim, o MANE 76 representa um exemplo de um dispositivo de midia para recuperar dados de midia, em que o dispositivo de midia inclui um ou mais processadores configurados para receber informações que indicam pelo menos uma estrutura de dados de uma pluralidade de estruturas de dados que é provável de ser recuperada por uma pluralidade de dispositivos de usuário operada por uma respectiva pluralidade de usuários, em que a estrutura de dados inclui dados de midia, e para recuperar os dados de midia da estrutura de dados antes de receber solicitações para os dados de midia dos dispositivos de usuário. Os dispositivos de usuário podem incluir o dispositivo de cliente 40. O MANE 76 pode recuperar (ou seja, pré-buscar) os dados de midia, por exemplo, do dispositivo de servidor 60. Em alguns exemplos, o MANE 76 pode ser um elemento de rede de reconhecimento de DASH (DANE). Adicionalmente, o dispositivo de cliente 40 pode recuperar os dados de midia a partir do MANE 7 6, em vez de a partir do dispositivo de
Petição 870190063436, de 08/07/2019, pág. 60/102
56/78 servidor 60. Assim, qualquer um ou ambos dentre o dispositivo de cliente 40 e o MANE 7 6 pode aplicar as técnicas desta revelação para pré-buscar dados de mídia particulares que podem ser de interesse para um usuário.
[0107] A Figura 2 é um diagrama de bloco que ilustra um conjunto de componentes da unidade de recuperação 52 exemplificativo da Figura 1 em maior detalhe. Nesse exemplo, a unidade de recuperação 52 inclui a unidade de middleware de eMBMS 100, o cliente de DASH 110 e a aplicação de mídia 112.
[0108] Nesse exemplo, a unidade de middleware de eMBMS 100 inclui adicionalmente a unidade de recepção de eMBMS 106, o cache 104 e a unidade de servidor proxy 102. Nesse exemplo, a unidade de recepção de eMBMS 106 é configurada para receber dados através de eMBMS, por exemplo, de acordo com Entrega de Arquivo durante 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. Ou seja, a unidade de recepção de eMBMS 106 pode receber arquivos através de difusão, por exemplo, a partir do dispositivo de servidor 60, que pode atuar como um BM-SC.
[0109] À medida que a unidade de middleware de eMBMS 100 recebe dados para arquivos, a unidade de middleware de eMBMS pode armazenar os dados recebidos no cache 104. O Cache 104 pode compreender um meio de armazenamento legível por computador, como memória flash, um disco rígido, RAM ou qualquer outro meio de
Petição 870190063436, de 08/07/2019, pág. 61/102
57/78 armazenamento adequado.
[0110] A unidade de servidor proxy 102 pode atuar como um servidor para o cliente de DASH 110. Por exemplo, a unidade de servidor proxy 102 pode fornecer um arquivo de MPD ou outro arquivo de manifesto para o cliente de DASH 110. A unidade de servidor proxy 102 pode divulgar períodos de disponibilidade para segmentos no arquivo de MPD, assim como hiperlinks a partir dos quais os segmentos podem ser recuperados. Esses hiperlinks podem incluir um prefixo de endereço de hospedeiro local correspondente ao dispositivo de cliente 40 (por exemplo, 127.0.0.1 para IPv4). Dessa maneira, o cliente de DASH 110 pode solicitar segmentos da unidade de servidor local 102 com o uso de solicitações de GET e de GET parcial de HTTP. Por exemplo, para um segmento disponível a partir do link http://127.0.0.l/repl/seg3, o cliente de DASH 110 pode elaborar uma solicitação de GET de HTTP que inclui uma solicitação para http://127.0.0.l/repl/seg3, e pode submeter a solicitação para a unidade de servidor proxy 102. A unidade de servidor proxy 102 pode recuperar os dados solicitados a partir do cache 104 e fornecer os dados para o cliente de DASH 110 em resposta a tais solicitações. O cliente de DASH 110 entrega dados de mídia recuperados a partir da unidade de servidor proxy 102 para a aplicação de mídia 112 para reprodução.
[0111] De acordo com certos exemplos das técnicas desta revelação, a unidade de middleware de eMBMS 100 pode receber dados de mídia que são prováveis de serem apresentados para um usuário através de eMBMS (por exemplo,
Petição 870190063436, de 08/07/2019, pág. 62/102
58/78 através de difusão/difusão múltipla), enquanto a unidade de recuperação 52 (consultar a Figura 1) (por exemplo, a unidade de middleware de eMBMS 100 ou o cliente de DASH 110) pode recuperar outros dados de midia que não são prováveis de serem apresentados para o usuário através de difusão única.
[0112] A Figura 3 é um diagrama conceituai que ilustra elementos do conteúdo multimídia 120 exemplificativo. O conteúdo multimídia 120 pode corresponder ao conteúdo multimídia 64 (Figura 1) ou a um outro conteúdo multimídia armazenado no meio de armazenamento 62. No exemplo da Figura 3, o conteúdo multimídia 120 inclui a descrição de apresentação de midia (MPD) 122 e uma pluralidade de representações 124A a 124N (representações 124) . A representação 124A inclui dados de cabeçalho opcionais 126 e segmentos 128A a 128N (segmentos 128) enquanto a representação 124N inclui dados de cabeçalho opcionais 130 e segmentos 132A-132N (segmentos 132). A letra N é usada para designar o último fragmento de video em cada uma das representações 124 por uma questão de conveniência. Em alguns exemplos, podem ser números diferentes de fragmentos de filme entre as representações 124 .
[0113] A MPD 122 pode compreender uma estrutura de dados separada das representações 124. A MPD 122 pode corresponder ao arquivo de manifesto 66 da Figura 1. Do mesmo modo, as representações 124 podem corresponder às representações 68 da Figura 2. Em geral, a MPD 122 pode incluir dados que descrevem, em geral, características das
Petição 870190063436, de 08/07/2019, pág. 63/102
59/78 representações 124, como características de codificação e renderização, conjuntos de adaptação, um perfil ao qual a MPD 122 corresponde, informações do tipo de texto, informações de ângulo de câmera, informações de classificação, informações de modo de truque (por exemplo, informações indicativas de representações que incluem subsequências temporais) e/ou informações para recuperar periodos remotos (por exemplo, para inserção de divulgação direcionada no conteúdo de midia durante a reprodução).
[0114] O MPD 122 sinaliza, em geral, características sobre várias estruturas de dados em vários níveis. Por exemplo, a MPD 122 sinaliza características sobre conjuntos de adaptação incluindo uma pluralidade de representações, as próprias representações, grupos de segmentos contidos em uma representação e segmentos individuais. A MPD 122 pode ser formada como documento de Linguagem Extensível de Marcação Genérica (XML), incluindo conjuntos recursivos de etiquetas. Assim, um nível de conjunto de adaptações pode ser formado com o uso de uma etiqueta de conjunto de adaptações, um nível de conjunto de representações pode ser formado com o uso de uma etiqueta de representação dentro de um conjunto de adaptações, um nível de grupo de segmentos pode ser formado com o uso de uma etiqueta de grupo de segmentos dentro de uma representação, e um nível de segmento pode ser formado com o uso de uma etiqueta de segmento dentro de um segmentos ou dentro de uma representação.
[0115] De acordo com as técnicas desta revelação, a MPD 122 pode incluir informações que indicam
Petição 870190063436, de 08/07/2019, pág. 64/102
60/78 pelo menos uma estrutura de dados de uma pluralidade de estruturas de dados que é provável de ser de interesse para um usuário, em que a estrutura de dados inclui dados de mídia. Por exemplo, a estrutura de dados pode ser uma apresentação de mídia, um conjunto de adaptações, uma representação ou uma subseção de uma representação (por exemplo, conjunto de um ou mais segmentos ou subsegmentos).
[0116] Conforme discutido acima, a MPD 122 pode incluir um elemento de RepRequestRate que inclui uma matriz de pares de dois atributos de {@repRequestRate, @validTimeEnd}. Nesse exemplo, um valor sem unidade para @repRequestRate pode indicar uma taxa de consumo ou solicitação relativa dentro da mesma apresentação de mídia para uma representação correspondente e um valor para @validTimeEnd pode indicar um tempo de término de linha de tempo de mídia para uma duração de tempo dentro da qual o valor @repRequestRate se aplica.
[0117] Em alguns exemplos, a MPD 122 pode incluir um valor para um elemento de sintaxe que representa uma taxa de consumo ou solicitação relativa de uma representação correspondente dentre todas as representações contidas na mesma apresentação de mídia para uma duração de tempo inteira da representação. O elemento de sintaxe pode corresponder a todas as representações contidas na mesma apresentação de mídia para um ou mais dentre um período de DASH, um conjunto de adaptações de DASH, uma representação de DASH ou uma sub-representação de DASH.
[0118] Em alguns exemplos, a MPD 122 pode incluir dados que representam taxas de consumo ou
Petição 870190063436, de 08/07/2019, pág. 65/102
61/78 solicitação relativas em partes temporais de dados de um conjunto de adaptações dentre todos os conjuntos de adaptação contidos na mesma apresentação de mídia.
[0119] Os dados de cabeçalho 126, quando presentes, podem descrever características de segmentos 128, por exemplo, localizações temporais de pontos de acesso aleatório (RAPs, chamados também de pontos de acesso de transmissão contínua (SAPs)), cujos segmentos 128 incluem pontos de acesso aleatório, deslocamentos de byte para pontos de acesso aleatório contidos nos segmentos 128, localizadores de recurso uniforme (URLs) dos segmentos 128 ou outros aspectos dos segmentos 128. Os dados de cabeçalho 130, quando presentes, podem descrever características similares para segmentos 132. Adicional ou alternativamente, tais características podem ser completamente incluídas dentro da MPD 122.
[0120] Os segmentos 128, 132 incluem uma ou mais amostras de vídeo codificadas, cada uma das quais inclui quadros ou fatias de dados de vídeo. Cada uma das amostras de vídeo codificadas dos segmentos 128 pode ter características similares, por exemplo, requisitos de altura, largura e largura de banda. Tais características podem ser descritas por dados da MPD 122, embora tais dados não sejam ilustrados no exemplo da Figura 3. A MPD 122 pode incluir características conforme descrito pela Especificação de 3 GPP, com a adição de qualquer uma ou de todas as informações sinalizadas nesta revelação.
[0121] Cada um dos segmentos 128, 132 pode ser associado com um único localizador de recurso uniforme
Petição 870190063436, de 08/07/2019, pág. 66/102
62/78 (URL) . Assim, cada um dos segmentos 128, 132 pode ser independentemente recuperável om o uso de um protocolo de rede de transmissão continua rede, como DASH. Dessa maneira, um dispositivo de destino, como dispositivo de cliente 40, pode ser usado em solicitação de GET de HTTP para recuperar segmentos 128 ou 132. Em alguns exemplos, o dispositivo de cliente 40 pode usar solicitações de GET parcial de HTTP para recuperar faixas especificas de bytes de segmentos 128 ou 132.
[0122] A Figura 4 é um diagrama de bloco que ilustra elementos de um arquivo de video 150 exemplificativo, que pode corresponder a um segmento de uma representação, como um dos segmentos 128, 132 da Figura 3. Cada um dos segmentos 128, 132 pode incluir dados que se conformam substancialmente com o arranjo de dados ilustrado no exemplo da Figura 4. Pode ser dito que o arquivo de video 150 encapsula um segmento. Conforme descrito acima, arquivos de video de acordo com o formato de arquivo de midia de base ISO e extensões dos mesmos armazenam dados em uma série de objetos chamados de caixas. No exemplo da Figura 4, o arquivo de video 150 inclui a caixa de tipo de arquivo (FTYP) 152, a caixa de filme (MOOV) 154, caixas de indice de segmento (sidx) 162, caixas de fragmento de filme (MOOF) 164 e a caixa de acesso aleatório ao fragmento de filma (MFRA) caixa 166. Embora a Figura 4 represente um exemplo de um arquivo de video, deve ser entendido que outros arquivos de midia podem incluir outros tipos de dados de midia (por exemplo, dados de áudio, dados de texto cronometrado ou similares) que são estruturados
Petição 870190063436, de 08/07/2019, pág. 67/102
63/78 similarmente aos dados de arquivo de vídeo 150 de acordo com o formato de arquivo de mídia de base ISO e suas extensões.
[0123] A caixa de tipo de arquivo (FTYP) 152 descreve, em geral, um tipo de arquivo para o arquivo de vídeo 150. A caixa de tipo de arquivo 152 pode incluir dados que identificam uma especificação que descreve um uso melhor para o arquivo de vídeo 150. A caixa de tipo de arquivo 152 pode, em várias alternativas, ser colocada imediatamente antes da caixa de MOOV 154, das caixas de fragmento de filme 164 ou da caixa de MFRA 166.
[0124] Em alguns exemplos, um Segmento, como arquivo de vídeo 150, pode incluir uma caixa de atualização de MPD (não mostrada) antes da caixa de FTYP 152. A caixa de atualização de MPD pode incluir informações que indicam que uma MPD correspondente a uma representação que inclui o arquivo de vídeo 150 deve ser atualizada junto com as informações para atualizar a MPD. Por exemplo, a caixa de atualização de MPD pode fornecer um URI ou URL para um recurso a ser usado para atualizar a MPD. Como um outro exemplo, a caixa de atualização de MPD pode incluir dados para atualização da MPD. Em alguns exemplos, a caixa de atualização de MPD pode seguir imediatamente uma caixa de tipo de segmento (STYP) (não mostrada) do arquivo de vídeo 150, em que a caixa de STYP pode definir um tipo de segmento para o arquivo de vídeo 150.
[0125] A caixa de MOOV 154, no exemplo da Figura 4, inclui a caixa de cabeçalho de filme (MVHD) 156, a caixa de faixa (TRAK) 158 e uma ou mais caixas de
Petição 870190063436, de 08/07/2019, pág. 68/102
64/78 extensão de filme (MVEX) 160. Em geral, a caixa de MVHD 156 pode descrever características gerais do arquivo de video 150. Por exemplo, a caixa de MVHD 156 pode incluir dados que descrevem quando o arquivo de video 150 foi criado originalmente, quando o arquivo de video 150 foi modificado por último, uma escala de tempo para o arquivo de video 150, uma duração de reprodução para o arquivo de video 150 ou outros dados que descrevem, em geral, o arquivo de video 150 .
[0126] A caixa de TRAK 158 pode incluir dados para uma faixa de arquivo de video 150. A caixa de TRAK 158 pode incluir uma caixa de cabeçalho de faixa (TKHD) que descreve características da faixa correspondente à caixa de TRAK 158. Em alguns exemplos, a caixa de TRAK 158 pode incluir imagens de video codificadas, enquanto em outros exemplos, as imagens de video codificadas da faixa podem ser incluídas em fragmentos de filme 164, que podem referenciados por dados da caixa de TRAK 158 e/ou caixas de sidx 162.
[0127] DE acordo com as técnicas desta revelação, a caixa de TRAK 158 pode incluir informações que indicam pelo menos uma estrutura de dados de uma pluralidade de estruturas de dados que é provável de ser recuperada por uma pluralidade de dispositivos de usuário operada por uma respectiva pluralidade de usuários, em que a estrutura de dados inclui dados de midia. Por exemplo, a caixa de TRAK 158 pode incluir uma pluralidade de faixas multiplexada, em que a pluralidade de faixas inclui faixas de midia para fragmentos de filme 164 e uma faixa separada
Petição 870190063436, de 08/07/2019, pág. 69/102
65/78 que tem elementos de sintaxe sinalizados em um nível de metadados temporizado que especifica as informações que indicam a pelo menos uma estrutura de dados da pluralidade de estruturas de dados que é provável de ser recuperada. A estrutura de dados pode compreender, por exemplo, um ou mais dos fragmentos de filme 164. Em alguns exemplos, a faixa separada pode ser formada como uma representação que não inclui quaisquer dados de mídia e multiplexada com outras faixas incluindo respectivas representações que incluem dados de mídia.
[0128] Em alguns exemplos, o arquivo de vídeo 150 pode incluir mais que uma faixa. Consequentemente, a caixa de MOOV 154 pode incluir diversas caixas de TRAK iguais ao número de faixas no arquivo de vídeo 150. A caixa de TRAK 158 pode descrever características de uma faixa correspondente de arquivo de vídeo 150. Por exemplo, a caixa de TRAK 158 pode descrever informações temporais e/ou espaciais para a faixa correspondente. Uma caixa de TRAK similar à caixa de TRAK 158 da caixa de MOOV 154 pode descrever características de uma faixa de conjunto de parâmetros quando a unidade de encapsulamento 30 (Figura 3) inclui uma faixa de conjunto de parâmetros em um arquivo de vídeo, como arquivo de vídeo 150. A unidade de encapsulamento 30 pode sinalizar a presença de mensagens de SEI em nível de sequência na faixa de conjunto de parâmetros contida na caixa de TRAK que descreve a faixa de conjunto de parâmetros.
[0129] As caixas de MVEX 160 podem descrever características de fragmentos de filme correspondente 164,
Petição 870190063436, de 08/07/2019, pág. 70/102
66/78 por exemplo, para sinalizar que o arquivo de vídeo 150 inclui fragmentos de filme 164, além de dados de vídeo incluídos na caixa de MOOV 154, se houver. No contexto de dados de vídeo de transmissão contínua, imagens de vídeo codificados podem ser incluídas em fragmentos de filme 164 e não na caixa de MOOV 154. Consequentemente, todas as amostras de vídeo codificadas podem ser incluídas em fragmentos de filme 164 e não na caixa de MOOV 154.
[0130] A caixa de MOOV 154 pode incluir diversas caixas de MVEX 160 iguais ao número de fragmentos de filme 164 no arquivo de vídeo 150. Cada uma das caixas de MVEX 160 pode descrever características de um fragmento correspondente dos fragmentos de filme 164. Por exemplo, cada caixa de MVEX pode incluir uma caixa de caixa de cabeçalho de extensão de filme (MEHD) que descreve uma duração temporal para o fragmento correspondente dos fragmentos de filme 164.
[0131] Conforme observado acima em relação à Figura 1, a unidade de encapsulamento 30 pode armazenar um conjunto de dados de sequência em uma amostra de vídeo que não inclui dados de vídeo codificados reais. Uma amostra de vídeo pode, em geral, corresponder a uma unidade de acesso, que é uma representação de uma imagem codificada em uma instância de tempo específica. No contexto de AVC, a imagem codificada inclui uma ou mais unidades de NAL com VCL que contêm as informações para elaborar todos os pixels da unidade de acesso e de outras unidades de NAL sem VCL associadas, como mensagens de SEI. Consequentemente, a unidade de encapsulamento 30 pode incluir um conjunto de
Petição 870190063436, de 08/07/2019, pág. 71/102
67/78 dados de sequência que pode incluir mensagens de SEI em nível de sequência em um dos fragmentos de filme 164. A unidade de encapsulamento 30 pode sinalizar adicionalmente a presença de um conjunto de dados de sequência e/ou mensagens de SEI em nível de sequência como estando presente em um dos fragmentos de filme 164 contido em uma das caixas de MVEX 160 correspondente a um dos fragmentos de caixa 164.
[0132] As caixas de SIDX 162 são elementos opcionais do arquivo de vídeo 150. Ou seja, os arquivos de vídeo em conformidade com o formato de arquivo 3GPP ou com outros tais formatos não incluem necessariamente caixas de SIDX 162. De acordo com o exemplo do formato de arquivo 3GPP, uma caixa de SIDX pode ser usada para identificar um subsegmento de um segmento (por exemplo, um segmento contido no arquivo de vídeo 150). O formato de arquivo 3GPP define um subsegmento como um conjunto autônomo de uma ou mais caixas de fragmento de filme consecutivas com caixa (caixas) de Dados de Mídia correspondente e uma caixa de Dados de Mídia que contém dados referenciados pela Caixa de Fragmento de Filme deve seguir essa caixa de Fragmento de Filme e preceder a próxima caixa d e Fragmento de Filme que contém informações sobre a mesma faixa. O formato de arquivo 3GPP indica também que uma caixa de SIDX caixa contém uma sequência de referências aos subsegmentos do (sub)segmento documentada pela caixa. Os subsegmentos são contíguos em tempo de apresentação. Similarmente, os bytes referidos como uma caixa de índice de Segmento são sempre contíguos dentro do segmento. O tamanho referenciado
Petição 870190063436, de 08/07/2019, pág. 72/102
68/78 proporciona a contagem de um número de bytes no material referenciados.
[0133] As caixas de SIDX 162 fornecem, em geral, informações representativas de um ou mais subsegmentos de um segmento incluido no arquivo de video 150. Por exemplo, tais informações podem incluir tempos de reprodução nos quais os subsegmentos começam e/ou terminam, deslocamentos de byte para o subsegmentos , um indicação de se os subsegmentos incluem (por exemplo, iniciam com) um ponto de acesso de transmissão continua (SAP), um tipo para o SAP (por exemplo, se o SAP é uma imagem instantânea de atualização de decodificador (IDR), uma imagem de acesso aleatório limpo (CRA), uma imagem de acesso de link quebrado (BLA) ou similares), uma posição do SAP (em termos de tempo de reprodução e/ou deslocamento de byte) no subsegmento e similares.
[0134] Os fragmentos de filme 164 podem incluir uma ou mais imagens de video codificadas. Em alguns exemplos, os fragmentos de filme 164 podem incluir um ou mais grupos de imagens (GOPs) , cada um dos quais pode incluir diversas imagens de video codificadas, por exemplo, quadros ou imagens. Além disso, conforme descrito acima, os fragmentos de filme 164 podem incluir conjuntos de dados de sequência em alguns exemplos. Cada um dos fragmentos de filme 164 pode incluir uma caixa de cabeçalho de fragmento de filme (MFHD, não mostrada na Figura 4). A caixa de MFHD pode descrever caracteristicas do fragmento de filme correspondente, como um número de sequência para o fragmento de filme. Os fragmentos de filme 164 podem ser
Petição 870190063436, de 08/07/2019, pág. 73/102
69/78 incluídos por ordem de número de sequência no arquivo de vídeo 150.
[0135] A caixa de MFRA 166 pode descrever pontos de acesso aleatório contidos em fragmentos de filme 164 do arquivo de vídeo 150. Isso pode ajudar com a realização de modos de truque, como realização de buscas de localizações temporais particulares (isto é, momentos de reprodução) dentro de um segmento encapsulado pelo arquivo de vídeo 150. A caixa de MFRA 166 é, em geral, opcional e não precisa ser incluída em arquivos de vídeo em alguns exemplos. Do mesmo modo, um dispositivo de cliente, como dispositivo de cliente 40, não precisa necessariamente fazer referência à caixa de MFRA 166 para decodificar e exibir corretamente dados de vídeo do arquivo de vídeo 150. A caixa de MFRA 166 pode incluir diversas caixas de acesso aleatório ao fragmento de faixa (TFRA) (não mostradas) iguais ao número de faixas do arquivo de vídeo 150, ou em alguns exemplos, iguais ao número de faixas de mídia (por exemplo, sem faixas de indicação) do arquivo de vídeo 150.
[0136] Em alguns exemplos, os fragmentos de filme 164 podem incluir um ou mais pontos de acesso de transmissão contínua (SAPs), como imagens de IDR. Do mesmo modo, a caixa de MFRA 166 pode fornecer indicações de localizações dentro do arquivo de vídeo 150 dos SAPs. Consequentemente, uma subsequência temporal do arquivo de vídeo 150 pode ser formada a partir dos SAPs do arquivo de vídeo 150. A subsequência temporal pode incluir também outras imagens, como quadros P e/ou quadros B que dependem dos SAPs. Os quadros e/ou fatias da subsequência temporal
Petição 870190063436, de 08/07/2019, pág. 74/102
70/78 podem ser dispostos dentro dos segmentos de modo que os quadros/fatias da subsequência temporal que dependem de outros quadros/fatias da subsequência possam ser decodificados apropriadamente. Por exemplo, no arranjo hierárquico de dados, os dados usados para outros dados podem ser incluidos na subsequência temporal.
[0137] A Figura 5 é um fluxograma que ilustra um método exemplificativo para realizar as técnicas desta revelação. O método da Figura 5 é explicado em relação ao dispositivo de servidor 60, ao MANE 76 e ao dispositivo de cliente 40 da Figura 1. Entretanto, deve ser entendido que esse método ou um método similar pode ser realizado por outros dispositivos, por exemplo, além de ou em alternativa ao dispositivo de servidor 60, ao MANE 76 e ao dispositivo de cliente 40. Por exemplo, as técnicas de pré-busca atribuidas ao MANE 76 podem, em vez disso, ser realizadas pelo próprio dispositivo de cliente 40. Como um outro exemplo, o dispositivo de preparação de conteúdo 20 pode realizar as técnicas atribuidas ao dispositivo de servidor 60. Nesse exemplo, o dispositivo de cliente 40 representa um dispositivo dentre uma pluralidade de dispositivos de usuário (por exemplo, equipamento de usuário (UE)), que pode ser, cada um, operado por um respectivo usuário diferente.
[0138] Inicialmente, nesse exemplo, o dispositivo de servidor 60 envia informações que indicam dados de midia que são prováveis de serem recuperados por uma pluralidade de usuários (200), por exemplo, usuários de dispositivos de cliente, como dispositivo de cliente 40.
Petição 870190063436, de 08/07/2019, pág. 75/102
71/78
Essas informações podem indicar um ou mais títulos (ou seja, filmes individuais, chamados de apresentações de mídia), conjuntos de adaptação de uma apresentação de mídia, representações de uma apresentação de mídia e/ou segmentos, grupos de segmentos ou subsegmentos de uma apresentação de mídia. Conforme discutido acima, tais informações podem ser incluídas em um arquivo de manifesto, como uma MPD de DASH, por exemplo, em um nível de MPD, em um nível de conjunto de adaptações, em um nível de representação, em um nível de segmento ou similares. Adicional ou alternativamente, essas informações podem ser incluídas em uma faixa que é multiplexada com outras faixas de um arquivo de vídeo. Adicional ou alternativamente, essas informações podem ser incluídas em uma mensagem de PED especial, por exemplo, que identifica particularmente uma MPD à qual a mensagem de PED se aplica, uma taxa de consumo ou solicitação relativa para uma apresentação de mídia correspondente à MPD e/ou dados que indicam taxas de consumo ou solicitação relativas para uma ou mais representações da apresentação de mídia.
[0139] Nesse exemplo, o MANE 76 recebe as informações (202) e usa as informações para determinar os dados de mídia que são prováveis de serem recuperados (204). Por exemplo, o MANE 76 pode extrair as informações a partir de uma MPD, uma mensagem de PED especial ou uma faixa separada de um arquivo de mídia. O MANE 7 6 pode, então, solicitar os dados de mídia que são prováveis de serem recuperados (206). Em particular, o MANE 76 pode prébuscar os dados de mídia que são prováveis de serem
Petição 870190063436, de 08/07/2019, pág. 76/102
72/78 recuperados. Ou seja, nesse exemplo, o MANE 76 recupera os dados de mídia que são prováveis de serem recuperados antes de qualquer um dentre a pluralidade de dispositivos de cliente (por exemplo, dispositivo de cliente 40) solicitar os dados de midia. Em outras palavras, o MANE 76 recupera os dados de mídia com o uso das informações que indica que os dados de mídia que são prováveis de serem recuperados, não em resposta às solicitações do dispositivo de cliente 40 (ou outros dispositivos de cliente).
[0140] O dispositivo de servidor 60 recebe a solicitação para os dados de mídia (208) e, em resposta à solicitação, envia os dados de mídia solicitados para o MANE 76 (210) nesse exemplo. O MANE 76 recebe e transfere por caches os dados de mídia (212), por exemplo, em uma memória do MANE 76 configurada como um cache. Dessa maneira, o MANE 76 tem os dados de mídia que são prováveis de serem recuperados por dispositivos de cliente antes dos dispositivos de cliente ter solicitado realmente os dados de mídia. Consequentemente, o MANE 7 6 pode servir solicitações para os dados de mídia do cache do MANE 76, em vez de recuperar os dados de mídia do dispositivo de servidor 60 após receber uma solicitação para os dados de mídia.
[0141] Em particular, conforme mostrado no exemplo da Figura 5, o dispositivo de cliente 40 solicita os dados de mídia que são prováveis de serem recuperados (214) . O MANE 76 recebe a solicitação para os dados de mídia do dispositivo de cliente 40 (216) . Como o MANE 7 6 pré-buscou os dados de mídia, o MANE 7 6 pode enviar os
Petição 870190063436, de 08/07/2019, pág. 77/102
73/78 dados solicitados de mídia para o dispositivo de cliente 40 (218), sem recuperar os dados de mídia a partir do dispositivo de servidor 60 após receber a solicitação do dispositivo de cliente 40. O dispositivo de cliente 40 pode, então, receber e apresentar os dados de mídia (220) . Dessa maneira, as técnicas desta revelação podem reduzir latência de resposta às solicitações para dados de mídia. Reduzir a latência dessa maneira pode aprimorar as experiências de usuários, e reduz também o processamento necessário pelo MANE 76. Em particular, ao transferir por cache os dados de mídia que são prováveis de serem recuperados através da pré-busca de tais dados de mídia, o MANE 76 pode assegurar que esses dados estão disponíveis
para uma pluralidade de usuários e, portanto, reduz o
número de vezes que o MANE 7 6 deve recuperar os dados de
mídia a partir do dispositivo de servidor 60 a fim de
servir os dados de mídia para a pluralidade de usuários.
[0142] Dessa maneira, o método da Figura 5
representa um exemplo de um método que inclui receber, por um dispositivo de mídia, informações que indicam pelo menos uma estrutura de dados de uma pluralidade de estruturas de dados que é provável de ser recuperada por uma pluralidade de dispositivos de usuário operada por uma respectiva pluralidade of usuários, em que a estrutura de dados inclui dados de mídia, e recuperar, pelo dispositivo de mídia, os dados de mídia da estrutura de dados antes de receber solicitações para os dados de mídia a partir dos dispositivos de usuário.
[0143] Conforme discutido acima, o método da
Petição 870190063436, de 08/07/2019, pág. 78/102
74/78
Figura 5 é explicado, para propósitos do exemplo, em relação ao MANE 7 6 que pré-busca dados de mídia. E outros exemplos, o dispositivo de cliente 40 pode pré-buscar dados de mídia, por exemplo, a partir dos MANE 76 ou dispositivo de servidor 60 antes de receber uma solicitação de um usuário do dispositivo de cliente 40 de uma maneira similar.
[0144] A Figura 6 é um fluxograma que ilustra um método exemplificativo para realizar as técnicas desta revelação. O método da Figura 6 é explicado em relação ao MANE 76 de servidor da Figura 1, para propósitos de exemplo. Entretanto, deve ser entendido que esse método ou um método similar pode ser realizado por outros dispositivos, por exemplo, além de ou em alternativa ao MANE 76. Por exemplo, o dispositivo de cliente 40 da Figura 1 pode realizar esse método ou um método similar. Do mesmo modo, o dispositivo de servidor 60 pode realizar um método conceitualmente, embora recíproco àquele mostrado na Figura 6. Ou seja, o dispositivo de servidor 60 pode enviar as informações indicadas como sendo recebidas e recuperadas pelo MANE 76 na Figura 6.
[0145] Inicialmente, o MANE 76 recebe informações que indicam pelo menos uma estrutura de dados de uma pluralidade de estruturas de dados que é provável de ser recuperada por uma pluralidade de dispositivos de usuário operada por uma respectiva pluralidade de usuários, em que a estrutura de dados inclui dados de mídia (230) . Então, o MANE 76 recupera os dados de mídia da estrutura de dados antes de receber solicitações para os dados de mídia
Petição 870190063436, de 08/07/2019, pág. 79/102
75/78 dos dispositivos de usuário (232) . Ou seja, o MANE 76 recupera os dados de mídia sem receber inicialmente solicitações para os dados de mídia dos dispositivos de cliente, isto é, não em resposta a quaisquer solicitações para os dados de mídia dos dispositivos de cliente. Dessa maneira, o MANE 76 pode pré-buscar os dados de mídia antes de os dados de mídia serem solicitados pelos dispositivos de cliente de modo que os dados de mídia estejam disponíveis para distribuição para os dispositivos de cliente no evento de solicitações para os dados de mídia dos dispositivos de cliente. Quando realizado por um dispositivo de cliente, como dispositivo de cliente 40 (Figura 1), o método da Figura 6 inclui, em geral, o dispositivo de cliente 40 que recupera os dados de mídia antes de receber quaisquer solicitações para os dados de mídia de um usuário do dispositivo de cliente 40 (isto é, não em resposta a uma solicitação para os dados de mídia do usuário) .
[0146] 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 durante uma ou mais instruções ou código
em um meio legível por computador e executadas por uma
unidade de processamento baseada em hardware. A mídia
legível por computador pode incluir mídia de armazenamento
legível por computador, que corresponde a um meio tangível,
como mídia de armazenamento de dados ou mídia de comunicação, incluindo qualquer meio que facilita a
Petição 870190063436, de 08/07/2019, pág. 80/102
76/78 transferência de um programa de computador de um lugar para um outro, por exemplo, de acordo com um protocolo de comunicação. Dessa maneira, a mídia legível por computador pode, em geral, corresponder à (1) mídia de armazenamento legível por computador tangível que é não transitória ou a (2) um meio de comunicação como um sinal ou uma onda portadora. 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 implementação das técnicas descritas nesta revelação. Um produto de programa de computador pode incluir um meio legível por computador.
[0147] A título de exemplo e não limitativa, tal mídia de armazenamento legível por computador pode compreender RAM, ROM, EEPROM, CD-ROM ou outros dispositivos de armazenamento de disco ótico ou armazenamento de disco magnético, memória flash ou qualquer outro meio que pode ser usado para armazenar código de programa desejado sob forma de instruções ou estruturas de dados e que pode ser acessado por um computador. Ademais, qualquer conexão é denominada apropriadamente como um meio legível por computador. Por exemplo, se as instruções forem transmitidas a partir de uma página de site, servidor ou outra fonte remota com o uso de um cabo coaxial, cabo de fibra ótica, par torcido, linha de assinante digital (DSL) ou tecnologias sem fio, como infravermelho, rádio e microonda, então o cabo coaxial, cabo de fibra ótica, par torcido, DSL ou tecnologias sem fio, como infravermelho,
Petição 870190063436, de 08/07/2019, pág. 81/102
77/78 rádio e micro-onda, são incluídos na definição de meio. Entretanto, deve ser entendido que a mídia de armazenamento legível por computador e a mídia de armazenamento de dados não incluem, conexões, ondas portadoras, sinais ou outra mídia transitória, mas são, em vez disso, direcionados para uma mídia de armazenamento não transitória e tangível. 0 disco magnético e o disco ótico, conforme usado no presente documento, incluem disco compacto (CD), disco a laser, disco ótico, disco versátil digital (DVD), disquete e disco do tipo Blu-ray em que os discos magnéticos reproduzem usualmente dados magneticamente enquanto os discos óticos reproduzem oticamente com lasers. Combinações dos elementos supracitados devem ser incluídas também dentro do escopo da mídia legível por computador.
[0148] As instruções podem ser executadas por um ou mais processadores, como um ou mais processadores de sinal digital (DSPs), microprocessadores de propósito geral, circuitos integrados de aplicação específica (ASICs), matrizes lógicas de campo programável (FPGAs) ou outro conjunto de circuitos lógicos discreto ou integrado. Consequentemente, o termo processador, conforme usado no presente documento, pode ser referir a qualquer uma dentre a estrutura supracitada ou qualquer outra estrutura adequada para implementação das técnicas descritas no presente documento. Além disso, em alguns aspectos, a funcionalidade descrita no presente documento pode ser fornecida dentro dos módulos de hardware e/ou software configurados para codificar e decodificar, ou incorporados em codec combinado. Ademais, as técnicas poderíam ser
Petição 870190063436, de 08/07/2019, pág. 82/102
78/78 implementadas em um ou mais circuitos ou elementos lógicos.
[0149] As técnicas desta revelação podem ser implementadas em uma variedade ampla de dispositivos ou aparelhos, incluindo um monotone sem fio, um circuito integrado (IC) ou um conjunto de ICs (por exemplo, com conjunto de chips). Vários componentes, módulos ou unidades são descritos nesta revelação para enfatizar os aspectos funcionais de dispositivos configurados para realizar as técnicas reveladas, mas não exige necessariamente a realização por unidades de hardware diferentes. Pelo contrário, conforme descrito acima, várias unidades podem ser combinadas em uma unidade de hardware de codec ou fornecidas por uma coleção de unidades de hardware interoperativas, incluindo um ou mais processadores conforme descrito acima, em conjunto com software e/ou firmware adequado.
[0150] Vários exemplos foram descritos. Esses e outros exemplos estão dentro do escopo das reivindicações a seguir.

Claims (42)

  1. REIVINDICAÇÕES
    1. Método de recuperação de dados de mídia, em que o método compreende:
    receber, por um dispositivo de mídia, informações que indicam pelo menos uma estrutura de dados de uma pluralidade de estruturas de dados que é provável de ser recuperada por uma pluralidade de dispositivos de usuário operada por uma respectiva pluralidade de usuários, em que a estrutura de dados inclui dados de mídia; e recuperar, pelo dispositivo de mídia, os dados de mídia da estrutura de dados antes de receber solicitações para os dados de mídia dos dispositivos de usuário.
  2. 2. Método, de acordo com a reivindicação 1, em que o dispositivo de mídia compreende um elemento de rede de reconhecimento de mídia (MANE) em comunicação com um dispositivo de servidor e com a pluralidade de dispositivos de usuário.
  3. 3. Método, de acordo com a reivindicação 1, em que o dispositivo de mídia compreende um elemento de rede de reconhecimento (DANE).de Transmissão Contínua Adaptativa Dinâmica por HTTP (DASH).
  4. 4. Método, de acordo com a reivindicação 1, em que a estrutura de dados compreende um dentre uma representação de Transmissão Contínua Adaptativa Dinâmica por HTTP (DASH) , um conjunto de adaptações de DASH ou um conjunto de apresentações de mídia que inclui uma pluralidade de representações de DASH relacionada e correspondente a um título de filme particular.
  5. 5. Método, de acordo com a reivindicação 1, em que o recebimento das informações compreende receber as
    Petição 870190063436, de 08/07/2019, pág. 84/102
    2/9 informações em um arquivo de manifesto para os dados de midia.
  6. 6. Método, de acordo com a reivindicação 5, em que o arquivo de manifesto compreende uma Descrição de Apresentação de Midia (MPD) de Transmissão Continua Adaptativa Dinâmica por HTTP (DASH).
  7. 7. Método, de acordo com a reivindicação 1, em que o recebimento das informações compreende receber as informações em uma mensagem de Entrega de Melhoria de Parâmetros (PED) que é separada de um arquivo de manifesto para os dados de midia.
  8. 8. Método, de acordo com a reivindicação 7, em que o dispositivo de midia compreende um elemento de rede de reconhecimento de midia (MANE) ou um elemento de rede de reconhecimento de DASH (DANE), em que o método compreende adicionalmente extrair as informações da mensagem de PED e atualizar as taxas de consumo ou solicitação relativas com o uso de informações extraidas.
  9. 9. Método, de acordo com a reivindicação 7, em que a mensagem de PED inclui um valor para um elemento @mpdld que identifica uma descrição de apresentação de midia (MPD) à qual a mensagem de PED se aplica, um valor para um elemento @contentRequestRate que indica uma taxa de consumo e de solicitação relativa para os dados de midia correspondentes à MPD e uma matriz de elementos de sintaxe {@repld, RepRequestRate} que indicam taxas de consumo ou solicitação relativas para respectivas representações.
  10. 10. Método, de acordo com a reivindicação 7, em que a mensagem de PED inclui uma MPD de DASH para os dados de midia.
    Petição 870190063436, de 08/07/2019, pág. 85/102
    3/9
  11. 11. Método, de acordo com a reivindicação 1, em que o recebimento das informações compreende receber valores para um atributo @contentRequestRate para as estruturas de dados, em que o atributo @contentRequestRate indica taxas de consumo ou solicitação para as respectivas estruturas de dados.
  12. 12. Método, de acordo com a reivindicação 11, em que o atributo @contentRequestRate tem um valor sem unidade que indica uma taxa de consumo ou solicitação de nivel de conteúdo ou de nivel de arquivo de manifesto para uma estrutura de dados correspondente, e em que um valor maior para o atributo @contentRequestRate indica que a estrutura de dados correspondente é mais provável de ser consumida ou solicitada que estruturas de dados que têm valores de atributo @contentRequestRate menores.
  13. 13. Método, de acordo com a reivindicação 11, em que o atributo @contentRequestRate tem um valor sem unidade que indica uma taxa de consumo ou solicitação de nível de conteúdo ou de nível de arquivo de manifesto para uma estrutura de dados correspondente, e em que um valor menor para o atributo @contentRequestRate indica que a estrutura de dados correspondente é mais provável de ser consumida ou solicitada que estruturas de dados que têm valores de atributo @contentRequestRate maiores.
  14. 14. Método, de acordo com a reivindicação 1, em que a estrutura de dados compreende um conjunto de adaptações ou uma representação, e em que o recebimento das informações compreende receber as informações em um nível de conjunto de adaptações ou em um nível de representação.
  15. 15. Método, de acordo com a reivindicação 14, em
    Petição 870190063436, de 08/07/2019, pág. 86/102
    4/9 que as informações indicam taxa de consumo ou de uma solicitação relativa em partes temporais de uma representação dentre todas as representações contidas na mesma apresentação de midia.
  16. 16. Método, de acordo com a reivindicação 14, em que as informações compreendem um elemento RepRequestRate que inclui uma matriz de pares de dois atributos de {@repRequestRate, @validTimeEnd}, em que um valor sem unidade para @repRequestRate indica uma taxa de consumo ou solicitação contida na mesma apresentação de midia para uma representação correspondente, e em que um valor para @validTimeEnd indica um tempo de término de linha de tempo de midia por uma duração de tempo dentro da qual o valor de @repRequestRate se aplica.
  17. 17. Método, de acordo com a reivindicação 14, em que as informações compreendem um valor que representa uma taxa de consumo ou solicitação relativa de uma representação correspondente dentre todas as representações contidas na mesma apresentação de midia por toda uma duração de tempo da representação.
  18. 18. Método, de acordo com a reivindicação 14, em que as informações compreendem um valor para um elemento de sintaxe que representa uma taxa de consumo ou solicitação relativa de uma representação correspondente dentre todas as representações contidas na mesma apresentação de midia para um ou mais de um periodo de DASH, um conjunto de adaptações de DASH, uma representação de DASH ou uma subrepresentação de DASH.
  19. 19. Método, de acordo com a reivindicação 18, em que as informações compreendem valores para elementos de
    Petição 870190063436, de 08/07/2019, pág. 87/102
    5/9 sintaxe sinalizados em dois ou mais dentre um nivel de periodo de DASH, um nivel de conjunto de adaptações de DASH, um nivel de representação de DASH ou um nivel de subrepresentação de DASH, em que o método compreende adicionalmente determinar se os valores sinalizados em niveis inferiores substituem os valores sinalizados em niveis superiores.
  20. 20. Método, de acordo com a reivindicação 18, que compreende adicionalmente determinar que um valor superior para o elemento de sintaxe que representa a taxa de consumo ou solicitação relativa indica que a representação correspondente é mais provável de ser recuperada que as representações que têm valores inferiores para o elemento de sintaxe.
  21. 21. Método, de acordo com a reivindicação 18, que compreende adicionalmente determinar que um valor inferior para o elemento de sintaxe que representa a taxa de consumo ou solicitação relativa indica que a representação correspondente é mais provável de ser recuperada que as representações que têm valores maiores para o elemento de sintaxe.
  22. 22. Método, de acordo com a reivindicação 14, em que o recebimento das informações compreende receber valores para elementos de sintaxe sinalizados em um nivel de metadados temporizado a partir de uma faixa multiplexada separada com uma ou mais faixas de midia.
  23. 23. Método, de acordo com a reivindicação 22, em que a extração dos valores compreende extrair os valores da faixa separada que é multiplexada com uma representação.
  24. 24. Método, de acordo com a reivindicação 22, em
    Petição 870190063436, de 08/07/2019, pág. 88/102
    6/9 que a extração dos valores compreende extrair os valores da faixa separada que é encapsulada em uma representação que não inclui dados de midia.
  25. 25. Método, de acordo com a reivindicação 14, em que as informações indicam taxas de consumo ou solicitação relativas em partes temporais dos dados de um conjunto de adaptações dentre todos os conjuntos de adaptação contidos na mesma apresentação de midia.
  26. 26. Método, de acordo com a reivindicação 14, em que o recebimento das informações no conjunto de adaptações ou no nivel de representação compreende extrair as informações de um arquivo de manifesto.
  27. 27. Método, de acordo com a reivindicação 1, em que a recuperação dos dados de midia compreende pré-buscar os dados de mídia.
  28. 28. Dispositivo de mídia para recuperar dados de mídia, em que o dispositivo de mídia compreende:
    uma memória para armazenar dados de mídia; e um ou mais processadores implementados no conjunto de circuitos e configurados para:
    receber informações que indicam pelo menos uma estrutura de dados de uma pluralidade de estruturas de dados que é provável de ser recuperada por uma pluralidade de dispositivos de usuário operada por uma respectiva pluralidade de usuários, em que a estrutura de dados inclui dados de mídia; e recuperar os dados de mídia da estrutura de dados antes de receber solicitações para os dados de mídia dos dispositivos de usuário.
  29. 29. Dispositivo de mídia, de acordo com a
    Petição 870190063436, de 08/07/2019, pág. 89/102
    7/9 reivindicação 28, em que a estrutura de dados compreende um dentre uma representação de Transmissão Continua Adaptativa Dinâmica por HTTP (DASH), um conjunto de adaptações de DASH ou um conjunto de apresentações de midia incluindo uma pluralidade de representações de DASH relacionadas correspondentes a um título de filme particular.
  30. 30. Dispositivo de mídia, de acordo com a reivindicação 28, em que o recebimento das informações compreende receber as informações em um arquivo de manifesto para os dados de mídia.
  31. 31. Dispositivo de mídia, de acordo com a reivindicação 30, em que o arquivo de manifesto compreende uma Descrição de Apresentação de Mídia (MPD).de Transmissão Contínua Adaptativa Dinâmica por HTTP (DASH).
  32. 32. Dispositivo de mídia, de acordo com a reivindicação 28, em que o recebimento das informações compreende receber as informações em uma mensagem de Entrega de Melhoria de Parâmetros (PED) que são separadas de um arquivo de manifesto para os dados de mídia.
  33. 33. Dispositivo de mídia, de acordo com a reivindicação 32, em que o dispositivo de mídia compreende um elemento de rede de reconhecimento de mídia (MANE) ou um elemento de rede de reconhecimento de DASH (DANE), e em que os um ou mais processadores são configurados adicionalmente para extrair as informações da mensagem de PED e atualizar as taxas de consumo ou solicitação relativas com o uso das informações extraídas.
  34. 34. Dispositivo de mídia, de acordo com a reivindicação 32, em que a mensagem de PED inclui um valor para um elemento @mpdld que identifica uma descrição de
    Petição 870190063436, de 08/07/2019, pág. 90/102
    8/9 apresentação de mídia (MPD) à qual a mensagem de PED se aplica, um valor para um elemento @contentRequestRate que indica uma taxa de consumo ou solicitação relativa para dados de mídia correspondentes à MPD e uma matriz de elementos de sintaxe de {@repld, RepRequestRate} que indicam taxas de consumo ou solicitação relativas para respectivas representações.
  35. 35. Dispositivo de mídia, de acordo com a reivindicação 28, em que a estrutura de dados compreende um conjunto de adaptações ou uma representação, e em que os um ou mais processadores são configurados para extrair as informações de um nível de conjunto de adaptações ou de um nível de representação de um arquivo de manifesto.
  36. 36. Dispositivo de mídia, de acordo com a reivindicação 28, em que os um ou mais processadores são configurados para pré-buscar os dados de mídia da estrutura de dados.
  37. 37. Dispositivo de mídia, de acordo com a reivindicação 28, que compreende adicionalmente um visor configurado para exibir uma imagem dos dados de mídia.
  38. 38. Dispositivo de mídia, de acordo com a reivindicação 28, em que o dispositivo de mídia compreende um ou mais dentre uma câmera, um computador, um dispositivo móvel, um dispositivo receptor de difusão ou um conversor do tipo set-top box.
  39. 39. Dispositivo de mídia de acordo com a reivindicação 28, em que o dispositivo de mídia compreende um elemento de rede de reconhecimento de mídia (MANE).
  40. 40. Dispositivo de mídia, de acordo com a reivindicação 28, em que o dispositivo de mídia compreende
    Petição 870190063436, de 08/07/2019, pág. 91/102
    9/9 um elemento de rede de reconhecimento (DANE) de Transmissão Contínua Adaptativa Dinâmica por HTTP (DASH).
  41. 41. Dispositivo de mídia para recuperar dados de mídia, em que o dispositivo de mídia compreende:
    meios para receber informações que indicam pelo menos uma estrutura de dados de uma pluralidade de estruturas de dados que é provável de ser recuperada por uma pluralidade de dispositivos de usuário operada por uma respectiva pluralidade de usuários, em que a estrutura de dados inclui dados de mídia; e meios para recuperar os dados de mídia da estrutura de dados antes de receber solicitações para os dados de mídia dos dispositivos de usuário.
  42. 42. Meio de armazenamento legível por computador que tem instruções armazenados no mesmo que, quando executadas, fazem com que um processador de um dispositivo de mídia:
    receba informações que indicam pelo menos uma estrutura de dados de uma pluralidade de estruturas de dados que é provável de ser recuperada por uma pluralidade de dispositivos de usuário operada por uma respectiva pluralidade de usuários, em que a estrutura de dados inclui dados de mídia; e recuperar os dados de mídia da estrutura de dados antes de receber solicitações para os dados de mídia dos dispositivos de usuário.
BR112019014070A 2017-01-10 2018-01-05 dados de sinalização para suporte de pré-busca para transmissão contínua de dados de mídia BR112019014070A2 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201762444730P 2017-01-10 2017-01-10
US15/862,251 US11290755B2 (en) 2017-01-10 2018-01-04 Signaling data for prefetching support for streaming media data
PCT/US2018/012600 WO2018132319A1 (en) 2017-01-10 2018-01-05 Signaling data for prefetching support for streaming media data

Publications (1)

Publication Number Publication Date
BR112019014070A2 true BR112019014070A2 (pt) 2020-02-04

Family

ID=62783504

Family Applications (1)

Application Number Title Priority Date Filing Date
BR112019014070A BR112019014070A2 (pt) 2017-01-10 2018-01-05 dados de sinalização para suporte de pré-busca para transmissão contínua de dados de mídia

Country Status (9)

Country Link
US (1) US11290755B2 (pt)
EP (1) EP3568991B1 (pt)
KR (1) KR102580982B1 (pt)
CN (1) CN110089122B (pt)
AU (1) AU2018207060A1 (pt)
BR (1) BR112019014070A2 (pt)
ES (1) ES2892329T3 (pt)
TW (1) TW201830974A (pt)
WO (1) WO2018132319A1 (pt)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3311577B1 (en) * 2015-06-16 2020-05-27 Intel IP Corporation A dynamic adaptive streaming over hypertext transfer protocol (dash) assisting network element (dane) transcoding media content based on a set of metric and status messages received from the dash client and corresponding dash client device
WO2018131813A1 (en) * 2017-01-10 2018-07-19 Samsung Electronics Co., Ltd. Method and apparatus for generating metadata for 3d images
KR102277267B1 (ko) * 2017-03-29 2021-07-14 엘지전자 주식회사 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
US10924822B2 (en) 2017-04-04 2021-02-16 Qualcomm Incorporated Segment types as delimiters and addressable resource identifiers
US10601886B2 (en) * 2018-02-05 2020-03-24 Telefonaktiebolaget Lm Ericsson (Publ) Method, a user equipment and a computer program product for enabling a dynamic adaptive streaming over HTTP, DASH, player to fetch media segments from a network
US11050843B2 (en) * 2018-03-30 2021-06-29 Facebook, Inc. Systems and methods for prefetching content
JP7028811B2 (ja) * 2019-01-29 2022-03-02 Kddi株式会社 コンテンツ配信ネットワークの転送装置
GB2582014A (en) * 2019-03-08 2020-09-09 Canon Kk Method, device, and computer program for optimizing transmission of portions of encapsulated media content
US10979477B1 (en) * 2019-03-26 2021-04-13 Amazon Technologies, Inc. Time synchronization between live video streaming and live metadata
KR102638636B1 (ko) * 2019-03-26 2024-02-21 구글 엘엘씨 다수의 암호화 디지털 서명들을 사용한 콘텐츠 액세스와 콘텐츠 전달의 인가 분리
WO2021156194A1 (en) * 2020-02-04 2021-08-12 Dolby International Ab Method and device for adaptive playout of media content
US11546406B2 (en) * 2020-04-13 2023-01-03 Tencent America LLC Media systems and methods including mixed event message tracks
US11394932B2 (en) 2020-06-03 2022-07-19 Honeywell International Inc. System and method for auto selecting a video for display on a mobile device based on the proximity of the mobile device relative to the video source
US11750815B2 (en) 2020-09-17 2023-09-05 Lemon, Inc. Versatile video coding track coding
US11611752B2 (en) 2020-10-07 2023-03-21 Lemon Inc. Adaptation parameter set storage in video coding
US11910032B1 (en) * 2022-08-02 2024-02-20 Rovi Guides, Inc. Systems and methods for distributed media streaming

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8090761B2 (en) 2002-07-12 2012-01-03 Hewlett-Packard Development Company, L.P. Storage and distribution of segmented media data
DE102005001286A1 (de) * 2005-01-11 2006-07-20 Siemens Ag Verfahren und Vorrichtung zur Übertragung von skalierbaren Daten
US20090183215A1 (en) 2008-01-16 2009-07-16 Qualcomm Incorporated Hybrid services: data, audio, and clipcast
CN101242430B (zh) 2008-02-22 2012-03-28 华中科技大学 对等网络点播系统中的定点数据预取方法
US8347340B2 (en) 2008-09-11 2013-01-01 Livetv, Llc Aircraft communications system with video file library and associated methods
WO2011139305A1 (en) * 2010-05-04 2011-11-10 Azuki Systems, Inc. Method and apparatus for carrier controlled dynamic rate adaptation and client playout rate reduction
CN101951395B (zh) 2010-08-30 2013-08-21 中国科学院声学研究所 一种基于访问预测的P2P VoD系统服务端的数据缓存策略
US9282354B2 (en) 2011-10-28 2016-03-08 Qualcomm Incorporated Method and apparatus to detect a demand for and to establish demand-based multimedia broadcast multicast service
US8903955B2 (en) * 2011-12-02 2014-12-02 Cisco Technology, Inc. Systems and methods for intelligent video delivery and cache management
US9804668B2 (en) * 2012-07-18 2017-10-31 Verimatrix, Inc. Systems and methods for rapid content switching to provide a linear TV experience using streaming content distribution
US20140089467A1 (en) * 2012-09-27 2014-03-27 Andre Beck Content stream delivery using pre-loaded segments
US9491457B2 (en) 2012-09-28 2016-11-08 Qualcomm Incorporated Signaling of regions of interest and gradual decoding refresh in video coding
US20140223502A1 (en) * 2013-02-06 2014-08-07 General Instrument Corporation Method of Operating an IP Client
EP3399763A1 (en) * 2013-05-24 2018-11-07 Immersion Corporation Method and system for haptic data encoding
US20140365613A1 (en) * 2013-06-06 2014-12-11 Ericsson Television Inc. Defragmentation of adaptive streaming segment files in a content delivery network
JP6444398B2 (ja) * 2013-07-03 2018-12-26 コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ セグメント化コンテンツのストリーミング
EP2833640A1 (en) * 2013-08-02 2015-02-04 British Telecommunications public limited company Video caching
US9444856B2 (en) * 2013-09-25 2016-09-13 Ericsson Ab System and method for managing adjacent channels in an adaptive streaming environment
US10841353B2 (en) * 2013-11-01 2020-11-17 Ericsson Ab System and method for optimizing defragmentation of content in a content delivery network
CN106664443B (zh) * 2014-06-27 2020-03-24 皇家Kpn公司 根据hevc拼贴视频流确定感兴趣区域
US9509742B2 (en) * 2014-10-29 2016-11-29 DLVR, Inc. Configuring manifest files referencing infrastructure service providers for adaptive streaming video
CN104486350B (zh) 2014-12-24 2017-11-10 电子科技大学 一种基于用户行为的网络内容加速方法
KR102379530B1 (ko) 2015-01-07 2022-03-29 삼성전자주식회사 통신 시스템에서 미디어 정보를 송수신하는 방법 및 장치
WO2016117904A1 (ko) * 2015-01-21 2016-07-28 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
CN110336843B (zh) 2015-02-24 2021-11-09 庄奇东 一种用于众包的内容分发方法、中心节点及边缘节点
US10375452B2 (en) * 2015-04-14 2019-08-06 Time Warner Cable Enterprises Llc Apparatus and methods for thumbnail generation
EP3311577B1 (en) * 2015-06-16 2020-05-27 Intel IP Corporation A dynamic adaptive streaming over hypertext transfer protocol (dash) assisting network element (dane) transcoding media content based on a set of metric and status messages received from the dash client and corresponding dash client device
US10193994B2 (en) 2015-06-18 2019-01-29 Qualcomm Incorporated Signaling cached segments for broadcast
US10096130B2 (en) * 2015-09-22 2018-10-09 Facebook, Inc. Systems and methods for content streaming
US10225546B2 (en) 2016-02-26 2019-03-05 Qualcomm Incorporated Independent multi-resolution coding
US10582201B2 (en) 2016-05-19 2020-03-03 Qualcomm Incorporated Most-interested region in an image
US11184624B2 (en) 2016-05-19 2021-11-23 Qualcomm Incorporated Regional random access in pictures
US10565463B2 (en) 2016-05-24 2020-02-18 Qualcomm Incorporated Advanced signaling of a most-interested region in an image
US10034033B2 (en) * 2016-07-28 2018-07-24 Cisco Technology, Inc. Predictive media distribution system
WO2018173876A1 (ja) * 2017-03-24 2018-09-27 ソニー株式会社 コンテンツ処理装置およびコンテンツ処理方法、並びにプログラム
US10062414B1 (en) * 2017-08-22 2018-08-28 Futurewei Technologies, Inc. Determining a future field of view (FOV) for a particular user viewing a 360 degree video stream in a network

Also Published As

Publication number Publication date
US20180199075A1 (en) 2018-07-12
AU2018207060A1 (en) 2019-06-13
ES2892329T3 (es) 2022-02-03
CN110089122A (zh) 2019-08-02
WO2018132319A1 (en) 2018-07-19
KR20190104147A (ko) 2019-09-06
KR102580982B1 (ko) 2023-09-20
US11290755B2 (en) 2022-03-29
CN110089122B (zh) 2021-12-10
EP3568991B1 (en) 2021-09-01
TW201830974A (zh) 2018-08-16
EP3568991A1 (en) 2019-11-20

Similar Documents

Publication Publication Date Title
CN110089122B (zh) 用于检索媒体数据的方法、媒体装置及计算机可读存储媒体
CN109076229B (zh) 在图片中最感兴趣的区域
KR102342274B1 (ko) 이미지에서 가장 관심있는 영역의 진보된 시그널링
BR112019019836A2 (pt) sinalização de informações importantes de vídeo em streaming de vídeo em rede usando parâmetros tipo mime
JP2019521584A (ja) Ｈｔｔｐを介した動的適応型ストリーミングにおけるバーチャルリアリティビデオのシグナリング
US11665219B2 (en) Processing media data using a generic descriptor for file format boxes
BR112020000110A2 (pt) sinalização de alto nível aprimorada para vídeo de realidade virtual de fisheye em dash
BR112020022899A2 (pt) sinalizar, em um arquivo de manifesto, seções ausentes de dados de mídia para rede de fluxo contínuo
KR20190039724A (ko) 미디어 데이터 스트리밍을 위한 sei 트랙들의 시스템 레벨 시그널링
AU2018301313B2 (en) Processing media data using an omnidirectional media format
KR102654999B1 (ko) 강화된 영역별 패킹 및 뷰포트 독립적 hevc 미디어 프로파일

Legal Events

Date Code Title Description
B350 Update of information on the portal [chapter 15.35 patent gazette]
B08F Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette]

Free format text: REFERENTE A 5A ANUIDADE.

B08K Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette]

Free format text: EM VIRTUDE DO ARQUIVAMENTO PUBLICADO NA RPI 2704 DE 01-11-2022 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDO O ARQUIVAMENTO DO PEDIDO DE PATENTE, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013.