BR112019019836A2 - sinalização de informações importantes de vídeo em streaming de vídeo em rede usando parâmetros tipo mime - Google Patents
sinalização de informações importantes de vídeo em streaming de vídeo em rede usando parâmetros tipo mime Download PDFInfo
- Publication number
- BR112019019836A2 BR112019019836A2 BR112019019836A BR112019019836A BR112019019836A2 BR 112019019836 A2 BR112019019836 A2 BR 112019019836A2 BR 112019019836 A BR112019019836 A BR 112019019836A BR 112019019836 A BR112019019836 A BR 112019019836A BR 112019019836 A2 BR112019019836 A2 BR 112019019836A2
- Authority
- BR
- Brazil
- Prior art keywords
- data
- video
- representation
- video data
- codecs
- Prior art date
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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
- H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
- H04N21/25808—Management of client data
- H04N21/25833—Management of client data involving client hardware characteristics, e.g. manufacturer, processing or storage capabilities
-
- 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/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4621—Controlling the complexity of the content stream or additional data, e.g. lowering the resolution or bit-rate of the video stream for a mobile client with a small screen
-
- 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/47—End-user applications
- H04N21/482—End-user interface for program selection
- H04N21/4825—End-user interface for program selection using a list of items to be played back in a given order, e.g. playlists
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/81—Monomedia components thereof
- H04N21/816—Monomedia components thereof involving special video data, e.g 3D video
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Library & Information Science (AREA)
- Human Computer Interaction (AREA)
- Computer Security & Cryptography (AREA)
- Computer Graphics (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
a presente invenção refere-se a um dispositivo exemplificativo para recuperação de dados de mídia inclui um ou mais processadores configurados para recuperar um arquivo manifesto especificando dados para pelo menos uma representação de uma apresentação de mídia, em que o arquivo manifesto inclui dados que especificam um ou mais codecs para a pelo menos uma representação, extrair, do arquivo manifesto, os dados que especificam os um ou mais codecs, os dados incluindo um primeiro elemento representando um código tipo de entrada de amostra de uma faixa da pelo menos uma representação, em que o primeiro elemento representa o código tipo de entrada de amostra usando um esquema restrito, e um segundo elemento representando um código tipo de esquema restrito para o esquema restrito da faixa, e recuperar os dados de mídia da pelo menos uma representação com base no primeiro elemento e no segundo elemento.
Description
SINALIZAÇÃO DE INFORMAÇÕES IMPORTANTES DE VÍDEO EM STREAMING DE VÍDEO EM REDE USANDO PARÂMETROS TIPO MIME [0001] Este pedido reivindica o benefício do Pedido de Provisório dos EUA N°. 62/477,350, depositado em 2 7 de março de 2 017, todo o conteúdo do qual é aqui incorporado por referência.
CAMPO TÉCNICO [0002] Esta invenção refere-se ao transporte de dados de mídia codificados.
FUNDAMENTO [0003] Os recursos de vídeo digital podem ser incorporados em uma ampla gama de dispositivos, incluindo televisão digital, sistemas de broadcast direto digital, sistemas de broadcast sem fio, assistentes pessoais digitais (PDAs), laptops ou computadores de mesa, câmeras digitais, dispositivos de gravação digital, reprodutores de mídia digital, dispositivos de videogame, consoles de videogame, radiotelefones por satélite ou celular, dispositivos de videoconferência e similares. Os dispositivos de vídeo digital implementam técnicas de compactação de vídeo, tais como as descritas nos padrões definidos por MPEG-2, MPEG-4, ITU-T H.263 ou ITU-T H.264/MPEG-4, Parse 10, Codi 1. icaçao Avançada de Vicie o (AVC) , ITU-T H.265 (também referido como Codificação de Vídeo de Alta Eficiência (HEVC)), extensões de tais padrões, para transmitir e receber informações de vídeo digital de forma, mais eficiente.
[0004] Após os dados de vídeo (e outros dados de mídia) serem codificados, os dados de vídeo podem ser empacotados para transmissão ou armazenamento. Os dados de
Petição 870190095055, de 23/09/2019, pág. 6/94
2/68 vídeo podem ser reunidos em ura. arquivo de vídeo compatível cora, qualquer ura de uma variedade de padrões, tais como o forraato de arquivo de raídia base da Organização Internacional para Padronização (ISO) e suas extensões, t. a. i s c orno AVC .
SUMÁRIO [0005] Era geral, esta invenção descreve técnicas para sinalização de informações importantes de vídeo relacionadas a vídeo de alta faixa dinâmica (HDR), ampla gama de cores (WCG), vídeo de realidade virtual/omnidirecional/360 graus, video em pacote de quadro, vídeo com alterações de orientação da exibição, vídeo armazenado usando o recurso de esquema restrito do formato de arquivo de mídia base ISO (ISOBMFF), e vídeo usando outros recursos que precisam de processamento de renderizaçâo pós-decodificaçâo especial para fornecer uma experiência visual desejável. Especificamente, vários parâmetros do tipo MIME exemplificativos são descritos, que podem expor tais informações importantes de vídeo em sistemas de alto nível sinalizando corpos de mensagem, por exemplo, arquivo de descrição de apresentação de mídia (MDP) de streaming adaptativo dinâmico sobre HTTP (DASH) (ou outro arquivo manifesto), tal que informações importantes de vídeo possam ser convenientemente acessadas por clientes de aplicativos, tais como clientes DASH, para tomar decisões de rejeição/seleção/aceitação/requisição de conteúdo. Ou seja, os clientes DASH podem usar essas informações para selecionar um conjunto apropriado de dados de mídia (por exemplo, uma representação DASH apropriada), em. que os dados de mídia podem. ser considerados
Petição 870190095055, de 23/09/2019, pág. 7/94
3/68 apropriados quando o dispositivo cliente é capaz de decodificar e renderizar os dados de mídia (por exemplo, o dispositivo cliente inclui um decodificador de vídeo que é capaz de decodificar dados de mídia incluídos na x e p r e s e n l a, ç a o L1A.S n , .
[0006] Em um exemplo, um método de recuperação de dados de mídia inclui recuperar um arquivo manifesto especificando dados para pelo menos uma representação de uma apresentação de mídia, em que o arquivo manifesto inclui dados que especificam, um ou mais codecs para a pelo menos uma representação; extrair, do arquivo manifesto, os dados que especificam os um ou mais codecs, incluindo: extrair um primeiro elemento representando um código tipo de entrada de amostra de uma faixa da pelo menos uma representação, em que o primeiro elemento representa que a faixa inclui dados de vídeo armazenados usando um esquema restrito; e extrair um segundo elemento representando um. código tipo de esquema restrito para o esquema restrito da. faixa; e recuperar dados de mídia da pelo menos uma representação com base no primeiro elemento e no segundo elemento.
[0007] Em outro exemplo, um dispositivo para recuperação de dados de mídia. inclui uma memória, configurada para armazenar dados de mídia; e ura ou mais processadores implementados em circuito e configurados para: recuperar um arquivo manifesto especificando dados para, pelo menos uma representação de uma apresentação de mídia, em que o arquivo manifesto inclui dados que especificam um ou mais codecs para a pelo menos uma representação; extrair, do arquivo manifesto, os dados que
Petição 870190095055, de 23/09/2019, pág. 8/94
4/68 especificam os um ou mais codecs, os dados incluindo um primeiro elemento representando um código tipo de entrada, de amostra de uma faixa da pelo menos uma representação, em que o primeiro elemento representa que a faixa inclui dados de vídeo armazenados usando um esquema restrito, e um segundo elemento representando um código tipo de esquema restrito para o esquema restrito da faixa; e recuperar os dados de mídia da pelo menos uma representação com base no primeiro elemento e no segundo elemento.
[0008] Em outro exemplo, um dispositivo para, recuperação de dados de mídia inclui meios para recuperação de um arquivo manifesto especificando dados para pelo menos uma representação de uma apresentação de mídia, em que o arquivo manifesto inclui dados que especificam um ou mais codecs para a pelo menos uma representação; meios para extrair, do arquivo manifesto, os dados que especificam os um ou mais codecs, incluindo: meios para extrair um primeiro elemento representando um código tipo de entrada, de amostra de uma faixa da pelo menos uma representação, em que o primeiro elemento representa que a faixa inclui dados de vídeo armazenados usando um esquema restrito; e meios para extrair um segundo elemento representando um código tipo de esquema restrito para, o esquema restrito da faixa; e meios para recuperação· de dados de mídia da pelo menos uma representação com base no primeiro elemento e no segundo elemento.
[0009] Em outro exemplo, um meio de armazenamento legível por computador, tal como um meio de armazenamento legível por computador não transitório, tem nele armazenadas instruções que, quando executadas, levam o
Petição 870190095055, de 23/09/2019, pág. 9/94
5/68 processador a recuperar um arquivo manifesto especificando dados para, pelo menos uma representação de uma apresentação de mídia, em que o arquivo manifesto inclui dados que especificam um ou mais codecs para a pelo menos uma representação; extrair, do arquivo manifesto, os dados que especificam os um ou mais codecs, incluindo instruções que levam o processador a: extrair um primeiro elemento representando um código tipo de entrada de amostra de uma faixa da pelo menos uma representação, em que o primeiro elemento representa que a faixa inclui dados de vídeo armazenados usando um esquema restrito; e extrair um segundo elemento representando um código tipo de esquema restrito para o esquema restrito da faixa; e recuperar dados de mídia da pelo menos uma representação com. base no primeiro elemento e no segundo elemento.
[0010] Os detalhes de um ou mais exemplos são apresentados nos desenhos anexos e na descrição abaixo. Outros recursos, objetos e vantagens serão evidentes a. partir da descrição e dos desenhos, e a partir das reivindicações.
BREVE DESCRIÇÃO DOS DESENHOS [0011] A. Figura 1 é um diagrama. de blocos ilustrando um sistema exempli f icativo que implementa, técnicas para streaming de dados de mídia através de uma rede.
[0012] A Figura 2 é um diagrama de blocos ilustrando um. conjunto de componentes exemplificative de uma unidade de recuperação da Figura 1 em maiores detalhes.
[0013] A Figura 3 é um diagrama conceituai ilustrando elementos de exemplo conteúdo multimídia.
Petição 870190095055, de 23/09/2019, pág. 10/94
6/68 [0014] A Figura 4 é um diagrama de blocos ilustrando elementos de um arquivo de vídeo exemplificative, que pode corresponder a um segmento de uma representação.
[0015] A Figura 5 é um. fluxograma ilustrando um método exemplificative de acordo com as técnicas da presente invenção.
DESCRIÇÃO DETALHADA [0016] Em geral, esta invenção descreve técnicas para sinalização de informações importantes de vídeo relacionadas a video de alta faixa dinâmica (HDR) , ampla gama de cores (WCG), video de realidade virtual/omnidirecional/360 graus, video em pacote de quadro, vídeo com alterações de orientação da exibição, video armazenado usando o recurso de esquema restrito do formato de arquivo de mídia base ISO (ISOBMFF), e video usando outros recursos que precisam de processamento de renderização pós-decodif icação especial para fornecer uma. experiência visual desejável. Especificamente, vários parâmetros do tipo MIME exemplificativos são descritos, que podem expor tais informações importantes de video em sistemas de alto nível sinalizando corpos de mensagem, por exemplo, arquivo de descrição de apresentação de mídia. (MDP) de streaming adaptativo dinâmico sobre HTTP (DASH) (ou outro arquivo manifesto), tal que informações importantes de vídeo possam ser convenientemente acessadas por clientes de aplicativos, tais como clientes DASH, para tomar decisões de rejeição/seleção/aceitação/requisição de conteúdo. Ou seja, os clientes DASH podem usar essas informações para selecionar um. conjunto apropriado de dados
Petição 870190095055, de 23/09/2019, pág. 11/94
7/68 de mídia (por exemplo, uma representação DASH apropriada), em que os dados de mídia podem ser considerados apropriados quando o dispositivo cliente é capaz de decodificar e renderizar os dados de mídia (por exemplo, o dispositivo cliente inclui um. decodificador de vídeo que é capaz de decodificar dados de mídia incluídos na representação DASH).
[0017] Por exemplo, a presente invenção divulga vários métodos exemplificativos de sinalização de informações importantes de video relacionadas a vídeo armazenado usando um esquema restrito, vídeo HDR/WCG, vídeo VR/omnidirecional/360, vídeo em pacote de quadro, e vídeo com alterações de orientação de exibição, tal que as informações importantes de vídeo possam ser convenientemente acessadas por clientes de aplicativo, tais como clientes DASH, para tomar decisões de rejeição/seleção/aceitação/requisição de conteúdo. Um ou mais desses métodos podem ser realizados de forma, independente, ou em qualquer combinação.
[0018] No contexto deste documento, informações importantes de vídeo incluem informações de vídeo que podem ser usadas para seleção de conteúdo, por exemplo, seleção de uma faixa de vídeo ou uma parte da mesma para, consumo.
[0019] Padrões de codificação de vídeo incluem ITU-T H.261, ISO/IEC MPEG-1 Visual, ITU-T H.262 ou ISO/IEC MPEG-2 Visual, ITU-T H.263, ISO/IEC MPEG-4 Visual, ITU-T H.264 ou ISO/IEC MPEG-4 AVC, incluindo suas extensões de Codificação de Vídeo Escalonável (SVC) e Codificação de Vídeo Multivisualização (MVC), e Codificação de Vídeo de
Petição 870190095055, de 23/09/2019, pág. 12/94
8/68
Alta Eficiência (HEVC), também conhecida como ITU-T H.265 e ISO/IEC 23008-2, incluindo sua extensão de codificação escalonável (isto é, codificação de video de alta eficiência escalonável, SHVC) e extensão multivisualização (isto é, codificação de video de alta eficiência de multivisualização, MV-HeVC).
[0020] Ambas AVC e HEVC suportam vídeo em pacote de quadro indicado pela mensagem SEI de arranjo de pacote de quadro. HEVC também suporta um tipo diferente de vídeo em pacote de quadro indicado pela mensagem SEI de arranjo de pacote de quadro retangular segmentado. Para tal vídeo em pacote de quadro, o lado do decodificador deve aplicar uma transformação de desempacotamento especial para separar os componentes das duas vistas representadas no fluxo de bits de vídeo antes da exibição.
[0021] AVC e HEVC também suportam conteúdo de vídeo para, o qual o lado do decodificador deve aplicar uma transformação de rotação e/ou inversão à imagem decodificada cortada antes da exibição, indicada pela
| mensagem SEI de | orientação de exibição. | Tal | video ê também |
| referi do c orno | vídeo com alterações | de | orientação de |
| exibição. | |||
| [0022] | As técnicas desta ii | •ivenç | ão podem ser |
aplicadas a arquivos de vídeo compatíveis com dados de vídeo encapsulados de acordo com qualquer um de formato de arquivo de mídia base ISO, formato de arquivo de Codificação de Vídeo Escalonável (SVC), formato de arquivo de Codificação Avançada de Vídeo (AVC), formato de arquivo de Projeto de Parceria de Terceira Geração (3GPP) e/ou formato de arquivo de Codificação de Vídeo
Petição 870190095055, de 23/09/2019, pág. 13/94
9/68
Multivisualização (MVC), ou outros formatos de arquivo de vídeo similares.
[0023] Padrões de formato de arquivo incluem formato de arquivo de mídia base ISO (ISOBMFF, ISO/IEC 14496-12), e outros derivados do ISOBMFF, incluindo formato de arquivo MPEG-4 (ISO/IEC 14496-15), formato de arquivo 3GPP (3GPP TS 26.244) e formato de arquivos para famílias AVC e HEVC de codecs de vídeo (ISO/IEC 14496-15) . Propostas para. ISO/IEC 14496-12 e 14496-15 estão disponíveis em http://phenix.int evry.fr/mpeg/doc end user/documents/111 Geneva/wgll/wl5177 v6-wl5177. zip http : / /wgl 1. sc.2 9 . org/doc end user/documents/115 Geneva/wgl 1 /W16169-V2-wl6169.zip, respectivamente.
[0024] O ISOBMFF é usado como a base para muitos formatos de encapsulamento de codec, tal como o formato de arquivo AVC, bem como para muitos formatos de recipiente multimídia, tais como o formato de arquivo MPEG-4, o formato de arquivo 3GPP (3GP) e o formato de arquivo DVB.
[0025] Além de mídia contínua, tal como áudio e vídeo, mídia estática, tal como imagens, bem como metadados podem ser armazenados em um arquivo compatível com ISOBMFF. Os arquivos estruturados de acordo com ISOBMFF podem ser usados para muitos propósitos, incluindo a reprodução de arquivo de mídia local, o download progressivo de um arquivo remoto, segmentos para Streaming Adaptativo Dinâmico sobre HTTP (DASH), recipientes para o conteúdo a ser transmitido por streaming e suas instruções de empacotamento; e gravação de fluxos de mídia recebidos em tempo real.
Petição 870190095055, de 23/09/2019, pág. 14/94
10/68 [0026] Uma caixa é a estrutura de sintaxe elementar no ISOBMFF, incluindo um tipo de caixa codificada de quatro caracteres, a contagem de bytes da caixa e a carga útil. Um arquivo ISOBMFF consiste em uma sequência de caixas, e as caixas podem conter outras caixas. Uma caixa Filme (moov) contém, os metadados para os fluxos de mídia contínuos presentes no arquivo, cada um representado no arquivo como uma faixa. Os metadados para uma faixa são incluídos em. uma caixa Faixa (trak) , enquanto o conteúdo de mídia de uma faixa é incluído em uma caixa Dados de Mídia (mdat) ou diretamente em um arquivo separado. O conteúdo de mídia para faixas consiste em uma sequência de amostras, tais como unidades de acesso de áudio ou vídeo.
[0027] O ISOBMFF especifica os seguintes tipos de faixas: uma faixa de mídia, que contém um fluxo de mídia elementar, uma faixa de dica, que inclui instruções de transmissão de mídia ou representa um fluxo de pacotes recebido, e uma faixa de metadados programada, que compreende metadados sincronizados no tempo.
[0028] Embora originalmente projetado para armazenamento, o ISOBMFF provou ser muito valioso para streaming, por exemplo, para download progressivo ou DASH. Para fins de streaming, os fragmentos de filme definidos em ISOBMFF podem ser usados.
[0029] Os metadados para cada faixa incluem uma lista de entradas de descrição de amostra, cada uma fornecendo o formato de codificação ou encapsulamento usado na faixa e os dados de inicialização necessários para processar esse formato. Cada amostra é associada a uma das entradas de descrição de amostra da faixa.
Petição 870190095055, de 23/09/2019, pág. 15/94
11/68 [0030] O ISOBMFF permite especificar metadados específicos de amostra com vários mecanismos. Caixas especificas dentro da caixa Tabela de Amostras (stbl) foram padronizadas para responder a necessidades comuns. Por exemplo, uma caixa Amostra de Sincronização (stss) é usada para listar as amostras de acesso aleatório da faixa. O mecanismo de agrupamento de amostras permite mapear amostras de acordo com um tipo de agrupamento de quatro caracteres em grupos de amostras que compartilham, a mesma propriedade especificada como uma entrada de descrição de grupo de amostras no arquivo. Vários tipos de agrupamento foram especifiçados no ISOBMFF.
[0031] As informações de alta faixa dinâmica (HDR) e ampla, gama de cores (WCG) podem ser sinalizadas usando a ColourInformationBox, definida na cláusula 12.1.5 da especificação ISOBMFF. Por exemplo, o colour type pode ser definido como igual a 'nclx', o que indica que as informações mais importantes sobre HDR/WCG são transportadas nos campos colour primaries, transfer characteristics, matrix coefficients e lull range flag.
[0032] 0 ISOBMFF especifica um projeto de esquema restrito. O projeto de esquema restrito no ISOBMFF é usado para lidar com situações em que um autor de arquivo requer determinadas ações no dispositivo de reprodução ou renderizador, para permitir que os dispositivos de reprodução simplesmente inspecionem um. arquivo para descobrir tais requisitos para renderizar um fluxo de bits e evitar que os dispositivos de reprodução decodifiquem e renderizem. arquivos que requerem processamento adicional. O
Petição 870190095055, de 23/09/2019, pág. 16/94
12/68 mecanismo se aplica a qualquer tipo de codec de vídeo.
[0033] O mecanismo é semelhante à transformação de proteção de conteúdo, onde as entradas de amostra estão ocultas atrás de entradas de amostra genéricas, 'encv', 'enca' etc., indicando mídia criptografada ou encapsulada. O mecanismo análogo para vídeo restrito usa. uma transformação com a entrada de amostra genérica 'resv'. O método pode ser aplicado quando o conteúdo deve ser decodificado apenas por dispositivos de reprodução que possam apresentá-lo corretamente.
[00.34] O esquema restrito é especificado nas seções 8.15.1 a 8.15.3 da especificação ISOBMFF.
[0035] A cláusula. 8.15.4 da. especificação ISOBMFF define um tipo de esquema restrito particular para o vídeo era pacote de quadro.
[0036] Streaming adaptativo dinâmico sobre HTTP (DASH), especificado na ISO/IEC 23009-1, é um padrão para aplicativos de streaming HTTP (adaptativo) . Especifica, principalmente o forraato da descrição de apresentação de mídia (MPD), também conhecido como manifesto, e o formato de segmento de mídia. A MPD descreve a mídia disponível no servidor e permite que o cliente DASH baixe de forma autônoma a. versão da mídia, no tempo de mídia em que estiver interessado.
[0037] Um procedimento típico para streaming DASH com base em HTTP inclui as seguintes etapas:
1) Um cliente DASH obtém, a MPD de um. conteúdo de streaming, por exemplo, um filme. A MPD inclui informações sobre diferentes representações alternativas, por exemplo, taxa, de bits, resolução de video, taxa de quadros, idioma
Petição 870190095055, de 23/09/2019, pág. 17/94
13/68 de áudio, do conteúdo do streaming, bem. como os URLs dos recursos HTTP (o segmento de inicialização e os segmentos de raid!a) .
2) Com base nas informações na MPD e nas informações locais do cliente DASH, por exemplo, largura de banda de rede, capacidade de decodificação/exibição e preferência de usuário, o cliente solicita a(s) representação(ões) desejada(s), um segmento (ou uma parte do mesmo, por exemplo, um segmento parcial) de cada vez.
3) Quando o cliente DASH detecta, uma alteração na. largura de banda de rede, o cliente DASH solicita segmentos de uma representação diferente com uma taxa de bits mais compatível, idealmente a partir de um segmento que começa com um ponto de acesso aleatório.
[0038] Durante uma sessão de streaming HTTP, para responder a uma requisição do usuário para retornar a uma posição passada ou avançar para uma posição futura, o cliente DASH solicita segmentos antigos ou futuros a partir de um segmento que está próximo à posição solicitada pelo usuário e que idealmente começa com um ponto de acesso aleatório. O usuário também pode solicitar o avanço rápido do conteúdo, que pode ser realizado solicitando dados suficientes para decodificar apenas as imagens de video intracodificadas ou apenas um subconjunto temporal do fluxo de video.
[0039] No streaming HTTP, tal como DASH, as operações frequentemente usadas incluem HEAD, GET e GET parcial. A operação HEAD recupera um cabeçalho de um arquivo associado a um determinado localizador uniforme de recursos (URL) ou nome uniforme de recurso (URN) , sem.
Petição 870190095055, de 23/09/2019, pág. 18/94
14/68 recuperar uma carga útil associada ao URL ou URN. A operação GET recupera, um arquivo inteiro associado a um determinada URL ou URN. A operação GET parcial recebe um intervalo de bytes corno parâmetro de entrada e recupera um número continuo de bytes de um arquivo, em. que o número de bytes corresponde ao intervalo de bytes recebido. Assim, os fragmentos de filme podem ser fornecidos para streaming HTTP, porque uma operação GET parcial pode obter um ou mais fragmentos de filme individuais. Em um fragmento de filme, pode haver vários fragmentos de faixa de diferentes faixas. No streaming HTTP, uma apresentação de mídia pode ser uma coleção estruturada de dados acessível ao cliente. 0 cliente pode solicitar e baixar informações de dados de mídia para apresentar um serviço de streaming a um usuário.
[0040] No exemplo de streaming de dados 3GPP usando streaming HTTP, pode haver várias representações para dados de vídeo e/ou de áudio de conteúdo multimídia. Conforme explicado abaixo, diferentes representações podem corresponder a diferentes características de codificação (por exemplo, diferentes perfis ou níveis de um padrão de codificação de vídeo), diferentes padrões de codificação ou extensões de padrões de codificação (tais como extensões mu.ltivisualização e/ou escalonáveis) ou diferentes taxas de bits. 0 manifesto de tais representações pode ser definido· em uma estrutura de dados de uma Descrição de Apresentação de Mídia (MPD). Uma apresentação de mídia pode corresponder a uma coleção estruturada de dados que é acessível a um dispositivo cliente de streaming HTTP. O dispositivo cliente de streaming HTTP pode solicitar e baixar informações de dados de mídia para apresentar um serviço de
Petição 870190095055, de 23/09/2019, pág. 19/94
15/68 streaming a um usuário do dispositivo cliente. Uma apresentação de mídia pode ser descrita na estrutura de dados de MPD, que pode incluir atualizações da MPD.
[0041] Uma apresentação era mídia pode conter uma sequência de um ou mais Períodos. Cada período pode se estender até o início do próximo Período, ou até o final da apresentação de mídia, no caso do último período. Cada período pode conter uma ou mais representações para o mesmo conteúdo de mídia. Uma representação pode ser uma de um. número de versões codificadas alternativas de áudio, vídeo, texto programado ou outros dados desse tipo. As representações podem diferir por tipos de codificação, por exemplo, por taxa, de bits, resolução e/ou codec para, dados de vídeo e taxa de bits, 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 vídeo codificados correspondentes a um período particular do conteúdo multimídia e codificados de maneira específica.
[0042] As representações de um período particular podem ser atribuídas a um grupo indicado por um atributo na MPD indicativo de um conjunto de adaptação ao qual as representações pertencem. As representações no mesmo conjunto de adaptação são geralmente consideradas alternativas umas às outras, pois um dispositivo cliente pode alternar dinamicamente e sem interrupções entre essas representações, por exemplo, para executar a 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ção, tal que qualquer uma das representações pode ser selecionada para decodificação para
Petição 870190095055, de 23/09/2019, pág. 20/94
16/68 apresentar dados de mídia, tais como dados de vídeo ou dados de áudio, do conteúdo multimídia para o período correspondente. 0 conteúdo de mídia dentro de um período pode ser representado por uma representação do grupo 0, se presente, ou a combinação de, no máximo, uma representação de cada grupo diferente de zero, em alguns exemplos. Os dados de tempo para cada representação de um período poderá ser expressos em relação à hora de início do período.
[0043] 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 autoinicializante. Quando presente, o segmento de inicialização pode conter informações de inicialização para acessar a representação. Em geral, o segmento de inicialização não contém dados de mídia. Um segmento· pode ser referenciado exclusivamente por um identificador, tal como um. localizador uniforme de recurso (URL) , nome uniforme de recurso (URN) ou identificador uniforme de recurso (URI). A MPD pode fornecer os identificadores para cada segmento. Em alguns exemplos, a MPD também pode fornecer faixas de bytes na forma de um atributo de faixa, que podem corresponder aos dados para um segmento em. um arquivo acessível pelo URL, URN ou URI.
[0044] Diferentes representações podem ser selecionadas para recuperação substancialmente simultânea para diferentes tipos de dados de mídia. Por exemplo, um dispositivo cliente pode selecionar uma representação de áudio, uma representação de vídeo e uma representação de texto programada a partir da qual deve-se recuperar segmentos. Em alguns exemplos, o dispositivo cliente pode
Petição 870190095055, de 23/09/2019, pág. 21/94
17/68 selecionar conjuntos de adaptação particulares para executar a adaptação da largura de banda. Ou seja, o dispositivo cliente pode selecionar um conjunto de
(por exemplo, vídeo) e selecionar diretamente representações para outros tipos de mídia (por exemplo, texto áudio e/ou programado).
[0045] Realidade virtual (VR) é a capacidade de estar virtualmente presente em um mundo nâo físico criado pela, renderização de imagem e som sintético e/ou natural correlacionados pelos movimentos do usuário imerso, permitindo interagir com esse mundo. Com o recente progresso alcançado em dispositivos de renderização, tais como dispositivos de visualização montados na cabeça (HMD), e a criação de vídeo VR (geralmente também referido como vídeo 360 graus), uma qualidade significativa de experiência pode ser oferecida. Aplicações de VR incluem jogos, treinamento, educação, vídeo esportivo, compras on line, entretenimento em vídeo et [0046] Um sistema de VR típico pode usar os seguintes componentes e etapas:
1) Um conjunto de câmeras, que normalmente inclui várias câmeras individuais apontando em direções diferentes e, idealmente, cobrindo coletivamente todos os pontos de vista ao redor do conjunto de câmeras.
2) Costura de imagem., em que as imagens de vídeo
Petição 870190095055, de 23/09/2019, pág. 22/94
18/68 captadas pelas várias câmeras individuais são sincronizadas no domínio de tempo e costuradas no domínio de espaço, para, serem um video esférico, mas mapeadas para um formato retangular, tal como equirretangular (como um mapa mundi) o u m. a p a c u b i c o .
3) 0 vídeo no formato retangular mapeado é codificado/compactado usando um codec de vídeo, por exemplo, H.265/HEVC ou H.264/AVC.
4) 0(s) fluxo (s) de bit de vídeo compactado pode (m) ser armazenado (s) e/ou encapsulado (s) em. um formato de mídia e transmitido(s) (possivelmente apenas o subconjunto que cobre a área sendo vista por um usuário) através de uma. rede para um receptor.
5) 0 receptor recebe o(s) fluxo(s) de vídeo ou parte dele(s), possivelmente encapsulado em um formato, e envia o sinal de vídeo decodificado ou parte dele para um dispositivo de renderização.
6) 0 dispositivo de renderização pode ser, por exemplo, um HMD, que pode rastrear o movimento de cabeça e até o momento de movimento dos olhos e renderizar a parte correspondente do vídeo que uma experiência imersiva é e n t r e gu e a o u. s u á r .í o .
[0047] O Formato de Aplicativo de Mídia. Omnidirecional (OMAF) está sendo desenvolvido pelo MPEG para definir um formato de aplicativo de mídia que permita aplicativos de mídia omnidirecional, com foco em aplicativos de VR com vídeo 360 graus e áudio associado. O OMZiF especifica uma lista de métodos de projeção que podem ser usados para conversão de um vídeo esférico ou 360° em um. vídeo retangular bidimensional, seguido de como
Petição 870190095055, de 23/09/2019, pág. 23/94
19/68 armazenar mídia omnidirecional e os metadados associados usando o formato de arquivo de mídia base ISO (ISOBMFF) e como encapsular, sinalizar e transmitir mídia omnidirecional usando streaming adaptativo dinâmico sobre HTTP (DASH), e finalmente quais codecs de vídeo e áudio, bem como configurações de codificação de mídia, podem ser usados para compressão e reprodução do sinal de mídia omnidirecional.
[0048] O OMAF pretende ser padronizado como ISO/IEC 23000-20, e uma especificação proposta, referida, como OMAF Committee Draft (CD), está disponível em http://wgll.sc.29.org/doc end user/documents/117 Geneva/wgll /wl6 636.z ip.
[0049] A. cláusula 7.1 da OMAF CD define um tipo de esquema restrito particular para o vídeo VR/omnidirecional/360, 'odvd' . A OMAF CD especifica que, quando o scheme_type é igual a ,odvd/, a caixa Informações do Esquema ('schi') precisa conter uma. ProjectedOmnidirectionalVideoBox ('povd') ou uma
FisheyeOmnidirectionalVideoBox ('fovd'). A OMAF CD especifica uma caixa 'povdí que contém uma ProjectionFormatBox, que carrega o geometry type e o pro j ection type. Na OMAF CD, o geometry type pode indicar uma geometria de esfera, por exemplo, e o projection type pode indicar a projeção equirretangular, uma projeção de mapa cúbico ou algum outro tipo de projeção. Essas informações são todas importantes para fins de seleção de conteúdo.
[0050] A especificação DASH inclui a definição dos atributos de MPD @mimeType e @codecs, os quais podem.
Petição 870190095055, de 23/09/2019, pág. 24/94
20/68 ser transmitidos no nível de Conjunto de Adaptação, Representação ou Sub-Representação.
[0051] O atributo @mimeType é definido da
| õ ΘCJi.lin LΘ f 01210.3 Π3 C j_ 3US lí.1 3 5,3.7,2 Cl3 Θ SpGC j_ t ± C3Ç3.O DAbH ’ | ||
| @mimeType | M | Especifica o tipo MIME da concatenação do Segmento de Inicialização, se presente, e todos os segmentos de mídia consecutivos na representação. |
[0052] Além disso, especificação DASH, a semântica é esclarecida da seguinte forma baseadas em ISOBMFF:
O atributo @mimeType ser fornecido de acordo com na cláusula 7.3.1 da do atributo gmimeType ainda, para apresentações de mídia de cada Representação deve a RFC 4337. Parâmetros adicionais podem ser adicionados de acordo cora a RFC 6381.
[0053] O atributo @codecs é definido da seguinte orma na seção da especificação DASH:
Especifica os codecs presentes dentro da Representação. Os parâmetros de codec devem também incluir as informações de perfil e nível, quando aplicável. Para formatos de segmento definidos nesta especificação, este elemento deve estar presente e o conteúdo deste atributo deve ser compatível com as produções de simplest ou fancy-list da RFC6381, Seção 3.2, sem os caracteres DQUOTE de fechamento. O identificador codec para o formato de mídia da Representação, mapeado no espaço de nome para codecs, conforme especificado na RFC6381, Seção 3.3, deve ser usado.
[0054] A cláusula E da ISO/IEC 14496-15 define o parâmetro 'codecs' para AVC, HEVC e suas extensões.
Petição 870190095055, de 23/09/2019, pág. 25/94
21/68 [0055] De acordo com a cláusula E da ISO/IEC 14496-15 e RFC6381, o parâmetro 'codecs' é um parâmetro opcional tipo MIME. No entanto, a ISO/IEC 14496-15 e a RFC6381 não deixam claro se o parâmetro 'codecs' pode ser transmitido como parte do atributo gmimeType.
[0056] Conforme especificado na RFC6381, o parâmetro 'codecs' é um valor único ou uma lista de valores separados por vírgulas, em que cada valor consiste em mais um ou mais elementos separados por pontos (por exemplo, delimitados por ponto) . O espaço de nome para o primeiro elemento é determinado pelo tipo MIME. O espaço de nome para cada elemento subsequente é determinado pelo elemento anterior. Para o ISOBMFF, o primeiro elemento de um valor do parâmetro codecs é um código de quatro caracteres da
sinalização de vídeo HDR/WCG, vídeo VR/omnidirecional/360, vídeo em pacote de quadro, vídeo com alterações de orientação de exibição e vídeo armazenado usando um esquema restrito podem encontrar os seguintes problemas:
1) Falta de um mecanismo para indicar o uso de um esquema restrito, bem como alguns detalhes importantes do esquema restrito usado em parâmetros tipo MIME, por exemplo, para vídeo VR/omnidirecional/360 e vídeo em pacote de quadro. Além disso, as seguintes questões/problemas não são claras.
a. Como os clientes DASH lidam com @mimeType contendo parâmetro opcional não reconhecido? Ignoram a parte não reconhecida e consideram o
Petição 870190095055, de 23/09/2019, pág. 26/94
22/68 restante como se a parte não reconhecida não existisse? Ou ignoram todo o Conjunto de Adaptação/Representação/Sub-Representação (isto é, não tenta solicitar/processar o Conjunto de Ad a p t a. ç ã o / R e p r e s e n t a ç ã o / S ub - R e p r e s e n t a. ç ã o qu e contém este atributo @mimeType)?
i. 0 último parece fazer mais sentido.
ii. A RFC 4337/RFC 6381 são silentes sobre a questão. Isso deve ser claramente especificado em algum lugar, de preferência, em uma atualização para a RFC 6381 (que atualiza a RFC 4337, por sinal).
b. Qual deve ser o parâmetro ’‘codecs’' para o vídeo armazenado usando um esquema restrito?
c. Um esquema restrito usado deve ser indicado pelo parâmetro 'codecs' ou um parâmetro tipo MIME diferente/separado? Existe algum problema de compatibilidade com versões anteriores se o parâmetro codecs for o mesmo que se nenhum esquema restrito fosse usado ao definir/ter um parâmetro tipo MIME opcional adicional para indicação do esquema restrito usado?
2) Para video com alterações de orientação de exibição, um esquema restrito especial está ausente, e também o primeiro problema acima se aplica.
3) Falta um mecanismo para incluir informações importantes de video para vídeo HDR/WCG como parte dos parâmetros do tipo MIME.
[0058] A Figura 1 é um diagrama de blocos
Petição 870190095055, de 23/09/2019, pág. 27/94
23/68 ilustrando um sistema exemplificative 10 que implementa técnicas para streaming de dados de mídia através de uma rede. Neste exemplo, o sistema 10 inclui o dispositivo de preparação de conteúdo 20, o dispositivo servidor 60 e o dispositivo cliente 40. O dispositivo cliente 40 e o dispositivo servidor 60 são comunicativamente acoplados pela rede 74, que pode compreender a Internet. Em alguns exemplos, o dispositivo de preparação de conteúdo 20 e o dispositivo servidor 60 também podem ser acoplados pela rede 74 ou outra rede, ou podem. ser diretamente comunicativamente acoplados. Em alguns exemplos, o dispositivo de preparação de conteúdo 20 e o dispositivo servidor 60 podem compreender o mesmo dispositivo.
[0059] O dispositivo de preparação de conteúdo 20, no exemplo da Figura 1, compreende uma fonte de áudio 22 e uma fonte de vídeo 24. A fonte de áudio 22 pode compreender, por exemplo, um microfone que produz sinais elétricos representativos dos dados de áudio capturados a. serem codificados pelo codificador de áudio 26. Alternativamente, a fonte de áudio 22 pode compreender um meio de armazenamento armazenando dados de áudio previamente gravados, um gerador de dados de áudio, tal como um sintetizador computadorizado ou qualquer outra, fonte de dados de áudio. A fonte de vídeo 24 pode compreender uma câmera de vídeo que produz dados de vídeo a serem codificados pelo codificador de vídeo 28, um meio de armazenamento codificado com dados de video previamente gravados, uma unidade de geração de dados de vídeo, tal como uma fonte gráfica de computador ou qualquer outra fonte de dados de vídeo. O dispositivo de preparação de
Petição 870190095055, de 23/09/2019, pág. 28/94
24/68 conteúdo 20 não é necessariamente acoplado contuni cativamente ao dispositivo servidor 60 em todos os exemplos, mas pode armazenar conteúdo multimídia em um meio separado que é lido pelo dispositivo servidor 60.
[0060] Dados brutos de áudio e vídeo podem compreender dados analógicos ou digitais. Gs dados analógicos podem ser digitalizados antes de serem codificados pelo codificador de áudio 26 e/ou pelo codificador de vídeo 28. A fonte de áudio 22 pode obter dados de áudio de um. participante locutor enquanto o participante locutor está falando, e a fonte de video 24 pode obter simultaneamente dados de vídeo do participante locutor. Em outros exemplos, a fonte de áudio 22 pode compreender um meio de armazenamento legível por computador compreendendo dados de áudio armazenados, e a fonte de vídeo 24 pode compreender um meio de armazenamento legível por computador compreendendo dados de vídeo armazenados. Dessa maneira, as técnicas descritas nesta invenção podem ser aplicadas a dados áudio e vídeo em tempo real, streaming ou ao vivo, ou a dados de áudio e vídeo prégravados e arquivados.
[0061] Os quadros de áudio que correspondem aos quadros de vídeo são geralmente quadros de áudio contendo dados de áudio que foram capturados (ou gerados) pela fonte de áudio 22 contemporaneamente com dados de vídeo capturados (ou gerados) pela fonte de vídeo 2 4 que está contida nos quadros de vídeo. Por exemplo, enquanto um participante locutor geralmente produz dados de áudio falando, a fonte de áudio 22 captura os dados de áudio, e a fonte ae v.i.cteo z4 captura ciados cie vrcieo do par ticipaute
Petição 870190095055, de 23/09/2019, pág. 29/94
25/68 locutor ao mesmo tempo, ou seja, enquanto a fonte de áudio 22 está capturando os dados de áudio. Portanto, um quadro de áudio pode corresponder temporalmente a um ou mais quadros de video particulares. Consequentemente, um quadro de áudio correspondente a um quadro de video geralmente corresponde a uma situação em que dados de áudio e dados de vídeo foram capturados ao mesmo tempo e para os quais um quadro de áudio e um quadro de vídeo compreendem, respectivamente, os dados de áudio e os dados de vídeo que foram capturados ao mesmo tempo.
[0062] Em alguns exemplos, o codificador de áudio 26 pode codificar um registro de data/hora em cada quadro de áudio codificado que representa um horário em que os dados de áudio para o quadro de áudio codificado foram gravados e, da mesma forma, o codificador de vídeo 28 pode codificar um registro de data/hora em cada quadro de vídeo codificado que representa um horário em que os dados de vídeo para o quadro de vídeo codificado foram, gravados. Nesses exemplos, ura quadro de áudio correspondente a um quadro de vídeo pode compreender um quadro de áudio que compreende um registro de data/hora e um quadro de vídeo que compreende o mesmo registro de data/hora. O 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 o codificador de vídeo 28 podem gerar os registros de data/hora, ou que a fonte de áudio 22 e a fonte de vídeo 24 podem usar para associar dados de áudio e vídeo, respectivamente, com um registro de data/hora.
Petição 870190095055, de 23/09/2019, pág. 30/94
26/68 correspondentes a uma hora em que os dados de áudio foram, gravados, e a fonte de video 24 pode enviar dados ao codificador de video 28, correspondentes a uma hora em que os dados de video foram gravados. Em alguns exemplos, o codificador de áudio 26 pode codificar um identificador de sequência nos dados de áudio codificados para indicar uma ordem temporal relativa de dados de áudio codificados, mas sem necessariamente indicar um tempo absoluto no qual os dados de áudio foram gravados e, da mesma forma, o codificador de vídeo 28 também pode usar identificadores de sequência para indicar uma ordem temporal relativa de dados de vídeo codificados. Da mesma forma, em alguns exemplos, um identificador de sequência pode ser mapeado ou de outra forma correlacionado com um registro de data/hora.
[0064] O codificador de áudio 26 geralmente produz um fluxo de dados de áudio codificados, enquanto o codificador de vídeo 2 8 produz um. fluxo de dados de vídeo codificados. Cada fluxo de dados individual (seja de áudio ou de vídeo) pode ser referido como um fluxo elementar. Um fluxo elementar é um único componente digitalmente codificado (possivelmente compactado) de uma representação. Por exemplo, a parte de áudio ou vídeo codificado da
| '1? Θ p JC Θ S θ Ώ l. cl. Ç cl O | pode | ser um fluxo element | ar. Um fl | UXO | ||
| e 1 erae | ntar pedí | ϊ ser | convertido em ura fluxo | eleraentar | ||
| pacot | e (PES) | antes | de | ser encapsulado em | um arquivo | de |
| vídeo | . Dentro | da me. | sma | representação, um ID | 46 Í.1.UX O p | ode |
| ser u | S cl Q O p ci JC cí | di s t i | ..ngu | ir os pacotes PES per | tencentes a | um |
fluxo elementar do outro. A unidade básica de dados de um fluxo elementar é um pacote de fluxo elementar empacotado (PES) . Dessa forma, dados de vídeo codificados geralmente
Petição 870190095055, de 23/09/2019, pág. 31/94
27/68 correspondem a fluxos de vídeo elementares. Da mesma forma, os dados de áudio correspondem a um ou mais respectivos fluxos elementares.
[0065] Muitos padrões de codificação de vídeo, tais como ITU-T H.264/AVC e ITU-T H.265/Codifícação de Vídeo de Alta Eficiência (HEVC), definem a sintaxe, a semântica e o processo de decodifícação para fluxos de bits sem erros, qualquer um dos quais compatível com um determinado perfil ou nível. Os padrões de codificação de vídeo normalmente não especificam o codificador, mas o codificador é encarregado de garantir que os fluxos de bits gerados sejam compatíveis com o padrão de um decodificador. No contexto de padrões de codificação de vídeo, um perfil corresponde a um subconjunto de algoritmos, recursos ou ferramentas e restrições que se aplicam a eles. Conforme definido pelo padrão H.264, por exemplo, um perfil é um subconjunto de toda a sintaxe de fluxo de bits que é especificada pelo padrão H.264. Um nível corresponde às limitações do consumo de recursos do decodificador, tais como, por exemplo, memória e computação do decodificador, que são relacionadas à resolução das imagens, taxa de bits e taxa, de processamento de blocos. Um perfil pode ser sinalizado com um valor profile ide (indicador de perfil), enquanto um nível pode ser sinalizado com um valor levei ide (indicador de nível).
[0066] O padrão H.264, por exemplo, reconhece que, dentro dos limites impostos pela sintaxe de um determinado perfil, ainda é possível exigir uma grande variação no desempenho de codificadores e decodificadores, dependendo dos valores obtidos pelos elementos de sintaxe
Petição 870190095055, de 23/09/2019, pág. 32/94
28/68 no fluxo cie tal como tamanho especificado das i m a g e n s d. e c o d.
cadas. Q padrão H.2 64 ainda reconhece que, em muitas aplicações, não é prático nem econômico implementar um decodificador capaz de lidar com todos os usos hipotéticos da sintaxe em um perfil particular. Portanto, o padrão H.264 define um nível como um conjunto especificado de restrições impostas aos valores dos elementos de sintaxe no fluxo de bits. Essas restrições podem ser simples limites aos valores. Alternativamente, essas restrições podem assumir a forma de restrições nas combinações aritméticas de valores (por exemplo, largura da imagem multiplicada pela altura da imagem multiplicada pelo número de imagens decodificadas por segundo). 0 padrão H.264 ainda prevê que implementações individuais podem.
suportar um nível diferente para cada perfil suportado.
[0067] Um decodificador compatível com um perfil normalmente suporta todos os recursos definidos no perfil. Por exemplo, como um recurso de codificação, a codificação de imagem B não é suportada no perfil de linha de base de H.264/AVC, mas é suportada em outros perfis de H.264/AVC. Um decodificador compatível com um nível deve ser capaz de decodificar qualquer fluxo de bits que não requer recursos além das limitações definidas no nível. As definições de perfis e níveis podem ser úteis para a interpretabilidade. Por exemplo, durante a transmissão de vídeo, um par de definições perfil e nível pode ser negociado e acordado para. uma sessão de transmissão inteira. Mais especificamente, em H.264/AVC, um nível pode definir limitações no número de macroblocos que precisam ser processados, tamanho do buffer de imagem decodificada
Petição 870190095055, de 23/09/2019, pág. 33/94
29/68 (DPB), tamanho do buffer de imagem codificada (CPB), intervalo de vetor de movimento vertical, número máximo de vetores de movimento por dois MBs consecutivos, e se um bloco B pode ter partições de submacroblocos menores que 8x8 pixels. Dessa maneira, um decodificador pode determinar se o decodificador é capaz de decodificar adequadamente o fluxo de bits.
[0068] No exemplo da Figura 1, a unidade de encapsulamento 30 do dispositivo de preparação de conteúdo 20 recebe fluxos elementares compreendendo dados de video codificados do codificador de vídeo 28 e fluxos elementares compreendendo dados de áudio codificados do codificador de áudio 26. Em. alguns exemplos, o codificador de vídeo 28 e o codificador de áudio 26 podem, cada um, incluir formadores de pacote para formar pacotes PES a partir de dados codificados. Em outros exemplos, o codificador de vídeo 28 e o codificador de áudio 2 6 podem, cada um., fazer interface com os respectivos formadores de pacote para formar pacotes PES a partir de dados codificados. Ainda em outros exemplos, a unidade de encapsulamento 30 pode usar formadores de pacote para formar pacotes PES a partir de dados áudio e vídeo codificados.
[0069] O codificador de vídeo 28 pode codificar dados de vídeo de conteúdo multimídia de várias maneiras para produzir diferentes representações do conteúdo multimídia em várias taxas de bits e com várias características, tais como resoluções de pixel, taxas de quadro, conformidade com vários padrões de codificação, conformidade com vários perfis e/ou níveis de perfis para vários padrões de codificação, representações com uma ou
Petição 870190095055, de 23/09/2019, pág. 34/94
30/68 várias visualizações (por exemplo, para reprodução bidimensional ou tridimensional) ou outras características. Uma representação, como usado na presente invenção, pode compreender um de dados de áudio, dados de vídeo, dados de texto (por exemplo, para legendas), ou outros dados. A representação pode incluir um fluxo elementar, tal como um fluxo elementar de áudio ou um fluxo elementar de vídeo. Cada pacote PES pode usar um stream id que identifica o fluxo elementar ao qual o pacote PES pertence. A unidade de encapsulamento 30 é responsável pela compilação de fluxos elementares em arquivos de vídeo (por exemplo, segmentos) de varias representações.
[0070] A unidade de encapsulamento 30 recebe pacotes PES para, fluxos elementares de uma representação do codificador de áudio 2 6 e codificador de vídeo 2 8 e forma unidades da camada de abstração de rede (NAL) correspondentes a partir dos pacotes PES. Os segmentos de vídeo codificados podem ser organizados em unidades NAL, que fornecem uma representação de vídeo amigável à rede, abrangendo aplicações como videotelefonia, armazenamento, broadcast ou streaming de vídeo. As unidades NAL podem ser categorizadas em unidades NAL da. Camada de Codificação de Vídeo (VCL) e unidades NAL não VCL. As unidades VCL podem conter o mecanismo de compactação principal e podem incluir dados no nível de bloco, macrobloco e/ou fatia. Outras unidades NAL podem ser unidades NAL não VCL. Em alguns exemplos, uma imagem codificada em uma instância de tempo, normalmente apresentada como uma imagem codificada primária, pode estar contida em uma unidade de acesso, que node conter uma ou mais unidades NAL.
Petição 870190095055, de 23/09/2019, pág. 35/94
31/68 [0071] As unidades NAL não VCL podem incluir unidades NAL e unidades SEI NAL do conjunto de parâmetros, entre outros. Os conjuntos de parâmetros podem conter informações do cabeçalho no nível de sequência (nos conjuntos de parâmetros de sequência (SPS)) e as informações de cabeçalho no nível de imagem com alteração pouco frequente (nos conjuntos de parâmetros da imagem (PPS)). Com os conjuntos de parâmetros (por exemplo, PPS e SPS), as informações com alteração pouco frequente não precisam ser repetidas para cada sequência ou imagem, portanto, a eficiência de codificação pode ser melhorada. Além disso, o uso de conjuntos de parâmetros pode permitir
parâmetros podem, ser transm.itidas em um canal diferente de outras unidades NAL, tais como as unidades SEI NAL.
[0072] As Informações de Aprimoramento
portanto, nem sempre são obrigatórias para a implementação do decodificador compatível com o padrão. As mensagens SEI podem ser mensagens SEI no nível de sequência ou mensagens SEI no nível de imagem. Algumas informações no nível de
Petição 870190095055, de 23/09/2019, pág. 36/94
32/68 sequência podem estar contidas nas mensagens SEI, tais como as mensagens SEI de informações de escalabilidade no exemplo da SVC e mensagens SEI de informações de escalabilidade de visualização na MVC. Essas mensagens SEI exemplificativas podem transmitir informações sobre, por exemplo, extração de pontos de operação e características dos pontos de operação. Além disso, a unidade de encapsulamento 30 pode formar um arquivo manifesto, tal 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 linguagem de marcação extensível (XML).
[0073] A unidade de encapsulamento 30 pode fornecer dados para uma ou mais representações de conteúdo multimídia, juntamente cora o arquivo manifesto (por exemplo, o MPD) para a interface de saída 32. A interface de saída 32 pode compreender uma interface de rede ou uma interface para gravação em um meio de armazenamento, tal como uma interface USB (Barramento Serial Universal), um gravador de CD ou DVD, uma interface para mídia de armazenamento magnética ou flash, ou outras interfaces para armazenar ou transmitir dados de mídia. A unidade de encapsulamento 3 0 pode fornecer dados de cada uma das representações de conteúdo multimídia para a interface de saída 32, que pode enviar os dados ao dispositivo servidor 60 através de transmissão de rede ou mídia de armazenamento. No exemplo da Figura 1, o dispositivo servidor 60 inclui o meio de armazenamento 62 que armazena vários conteúdos multimídia 64, cada um incluindo o respectivo arquivo manifesto 66 e uma ou mais
Petição 870190095055, de 23/09/2019, pág. 37/94
33/68 representações 68A-68N (representações 68) . Em alguns exemplos, a interface de saída 32 também pode enviar dados diretamente para a rede 74.
[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 os respectivos conjuntos comuns de características, tais como codec, perfil e nível, resolução, número de visualizações, formato de arquivo para segmentos, informações sobre o tipo de texto que podem. identificar um idioma. ou outras características do texto a serem exibidas com a representação e/ou dados de áudio a serem decodificados e apresentados, por exemplo, por alto-falantes, informações de ângulo da. câmera que podem, descrever um ângulo da câmera ou perspectiva da câmera do mundo real de uma cena para representações no conjunto de adaptação, informações de classificação que descrevem, a adequação do conteúdo para públicos específicos, ou semelhantes.
[0075] O arquivo manifesto 66 pode incluir dados indicativos dos subconjuntos de representações 68 correspondentes a determinados conjuntos de adaptação, bem como características comuns para os conjuntos de adaptação. O arquivo manifesto 66 também pode incluir dados representativos de características individuais, tais como taxas de bits, para representações individuais de conjuntos de adaptação. Dessa maneira, um. conjunto de adaptação pode fornecer uma adaptação simplificada da largura de banda da
| rede | . As representaçõ | es em um conjunto | de | adaptação pc | >dem |
| ser | i n d i c adas u s ando | elementos filho | de | um elemento | do |
| conj' | unto de adaptação | do arqu.1 vo mani fe | S f' o | 6 6. |
Petição 870190095055, de 23/09/2019, pág. 38/94
34/68 [0076] O dispositivo servidor 60 inclui a unidade de processamento de requisição 70 e a interface de rede 72. Em alguns exemplos, o dispositivo servidor 60 pode incluir uma pluralidade de interfaces de rede. Além disso, qualquer um ou todos os recursos do dispositivo servidor 60 podem ser implementados em outros dispositivos de uma rede de distribuição de conteúdo, tais como roteadores, pontes, dispositivos proxy, comutadores ou outros dispositivos. Em alguns exemplos, os dispositivos intermediários de uma rede de distribuição de conteúdo podem armazenar em cache dados de conteúdo multimídia 64, e incluir componentes substancialmente compatíveis com os do dispositivo servidor 60. Em. geral, a interface de rede 72 é configurada para, enviar e receber dados através da rede 74.
[0077] A unidade de processamento de reguisição 70 é configurada para receber requisições de rede de dispositivos clientes, tais como o dispositivo cliente 40, para dados do meio de armazenamento 62. Por exemplo, a unidade de processamento de requisições 70 pode implementar o protocolo de transferência de hipertexto (HTTP) versão 1.1, como descrito na RFC 2616, Hypertext Transfer Protocol - HTTP/1.1, de R. Fielding et al., Network Working Group, IETF, junho de 1999. Ou seja, a. unidade de processamento de requisições 70 pode ser configurada para receber requisições HTTP GET ou GET parcial e fornecer dados de conteúdo multimídia 64 em resposta, às requisições. As requisições podem especificar um segmento de uma das representações 68, por exemplo, usando um URL do segmento. Em alguns exemplos, as requisições também podem especificar um. ou. mais intervalos de bytes do segmento, compreendendo
Petição 870190095055, de 23/09/2019, pág. 39/94
35/68 assim requisições GET parcial. A unidade de processamento de requisições 70 ainda pode ser configurada para, requisições HTTP HEAD de serviço para fornecer dados de cabeçalho de um segmento de uma das representações 68. Em qualquer caso, a unidade de processamento de requisições 70 pode ser configurada para processar as requisições para prover os dados solicitados a um dispositivo requisitante, tal como o dispositivo cliente 40.
[0078] Adicionalmente ou alternativamente, a unidade de processamento de requisições 70 pode ser configurada para fornecer dados de mídia através de um protocolo de broadcast ou multicast, tal como eMBMS. O dispositivo de preparação de conteúdo 20 pode criar segmentos DA.SH e/ou subsegmentos substancialmente da mesma maneira descrita, mas o dispositivo servidor 60 pode fornecer esses segmentos ou subsegmentos usando eMBMS ou outro protocolo de transporte de rede broadcast. ou multicast. Por exemplo, a unidade de processamento de requisição 70 pode ser configurada para receber, do dispositivo cliente 40, uma requisição de ingresso no grupo multicast. Ou seja, o dispositivo servidor 60 pode anunciar um endereço de protocolo de Internet (IP) associado com um grupo multicast a dispositivos clientes, incluindo o dispositivo cliente 40, associado a determinado conteúdo de mídia (por exemplo, um broadcast de um evento ao vivo) . O dispositivo cliente 40, por sua vez, pode submeter uma. requisição para ingressar no grupo multicast. Essa requisição pode ser propagada pela rede 74, por exemplo, roteadores que compõem a rede 74, tal que os roteadores direcionam, o tráfego direto destinado para o endereço IP
Petição 870190095055, de 23/09/2019, pág. 40/94
36/68 associado ao grupo multicast para assinar dispositivos clientes, tais como o dispositivo cliente 40.
[0079] Conforme ilustrado no exemplo da Figura 1, o conteúdo multimídia 64 inclui o arquivo manifesto 66, que pode corresponder a uma descrição de apresentação de mídia (MPD). O arquivo manifesto 66 pode conter descrições de diferentes representações alternativas 68 (por exemplo, serviços de vídeo com diferentes qualidades) e a descrição pode incluir, por exemplo, informações de codec, um valor de perfil, um valor de nível, uma taxa de bits e outras caracter!sticas descritivas de representações 68. O dispositivo cliente 40 pode recuperar o MPD de uma apresentação de mídia para determinar como acessar os 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 cliente 40 para determinar os recursos de decodificação do decodificador de vídeo 48 e render!zar os recursos de renderização da saída de video 44. Os dados de configuração também podem incluir qualquer uma ou toda a preferência de idioma selecionada por um usuário do dispositivo cliente 40, uma ou mais perspectivas da câmera correspondentes a preferências de profundidade definidas pelo usuário do dispositivo cliente 40 e/ou uma preferência de classificação selecionada pelo usuário do dispositivo cliente 40. A unidade de recuperação 52 pode compreender, por exemplo, um navegador web ou um cliente de mídia configurado para submeter requisições HTTP GET e GET parcial. A unidade de recuperação 52 pode corresponder às instruções de software executadas por um. ou mais
Petição 870190095055, de 23/09/2019, pág. 41/94
37/68 processadores ou unidades de processamento (não mostrados) do dispositivo cliente 40. Em. alguns exemplos, toda ou porções da funcionalidade descrita em relação à unidade de recuperação 52 podem ser implementadas em hardware, ou uma combinação de hardware, software e/ou firmware, eia que o hardware necessário pode ser fornecido para executar instruções para software ou firmware.
[0081] A unidade de recuperação 52 pode comparar os recursos de decodificação e renderização do dispositivo cliente 40 com as características de representações 68 indicadas pelas informações do arquivo manifesto 66. A unidade de recuperação 52 pode inicialmente recuperar pelo menos uma porção do arquivo manifesto 66 para determinar as características de representações 68. Por exemplo, a unidade de recuperação 52 pode solicitar uma porção do arquivo manifesto 66 que descreve características de um ou mais conjuntos de adaptação. A unidade de recuperação 52 pode selecionar um subconjunto de representações 68 (por exemplo, um conjunto de adaptação) com características que podem ser satisfeitas pelos recursos de codificação e renderização do dispositivo cliente 40. A unidade de recuperação 52 pode, então, determinar taxas de bits para representações no conjunto de adaptação, determinar uma. quantidade atualmente disponível de largura de banda de rede e recuperar segmentos de uma das representações com uma taxa de bits que pode ser satisfeita pela largura de Ό cl Π d 3 Cí Θ Θ d Θ » [0082] Em geral, representações de taxa de bits mais altas podem produzir uma reprodução de vídeo de qualidade mais alta, enquanto representações de taxa de
Petição 870190095055, de 23/09/2019, pág. 42/94
38/68 bits mais baixas podem, fornecer reprodução de vídeo de qualidade suficiente quando a largura de banda de rede disponível diminui. Por conseguinte, quando a largura de banda de rede disponível é relativamente alta, a unidade de recuperação 52 pode recuperar dados de representações de taxa, de bits relativamente altas, ao passo que, quando a largura de banda de rede disponível é baixa, a unidade de recuperação 52 pode recuperar dados de representações de taxa. de bits relativamente baixa. Dessa maneira, o dispositivo cliente 40 pode transmitir dados multimídia, pela rede 74, enquanto também se adapta à alteração da disponibilidade de largura de banda da rede 74.
[0083] Adicionalmente ou alternativamente, a. unidade de recuperação 52 pode ser configurada para receber dados de acordo com um protocolo de rede broadcast ou multicast, tal como eMBMS ou IP multicast. Nesses exemplos, a unidade de recuperação 52 pode submeter uma requisição para ingressar em um grupo de rede multicast associado a um determinado conteúdo de mídia. Após ingressar no grupo multicast, a unidade de recuperação 52 pode receber dados do grupo multicast sem requisições adicionais emitidas ao dispositivo servidor 60 ou dispositivo de preparação de conteúdo 20. A unidade de recuperação 52 pode submeter uma. requisição para deixar o grupo multicast quando os dados do grupo multicast não é mais necessário, por exemplo, para interromper a reprodução ou alterar canais para um grupo multicast 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 por sua
Petição 870190095055, de 23/09/2019, pág. 43/94
39/68 vez pode fornecer os segmentos à unidade de desencapsulamento 50. A unidade de desencapsulamento 50 pode desencapsular elementos de um arquivo de vídeo em fluxos PES constituintes, desempacotar os fluxos PES para recuperar dados codificados, e enviar os dados codificados para, o decodif icador de áudio 4 6 ou o decodif icador de vídeo 48, dependendo de se os dados codificados fazem parte de um fluxo de áudio ou vídeo, por exemplo, conforme indicado pelos cabeçalhos de pacote PES do fluxo. 0 decodificador de áudio 46 decodifica dados de áudio codificados e envia os dados de áudio decodificados para a saída de áudio 42, enquanto o decodificador de vídeo 48 decodifica os dados de vídeo codificados e envia os dados de vídeo decodificados, que podem ser uma pluralidade de visualizações de um fluxo, para a saída de vídeo 44.
[0085] O codificador de vídeo 28, o decodificador de vídeo 48, o codificador de áudio 26, o decodificador de áudio 46, a unidade de encapsulamento 30, a unidade de recuperação 52 e a unidade de desencapsulamento 50 podem, cada um, ser implementados como qualquer um de uma variedade de circuitos de processamento adequados, conforme aplicável, tais como um ou mais microprocessadores, processadores de sinal digital (DSPs), circuitos integrados de aplicação específica (ASICs), matrizes de portas programáveis em campo (FPGAs), circuitos de lógica discreta, software, hardware, firmware ou qualquer combinação dos mesmos. Cada codificador de video 28 e decodificador de vídeo 48 pode ser incluído em um ou mais codificadores ou decodificadores, que podem ser integrados como parte de um codificador/decodificador de vídeo
Petição 870190095055, de 23/09/2019, pág. 44/94
40/68 combinado (CODEC). Da mesma forma, cada codificador de áudio 2 6 e decodificador de áudio 4 6 pode ser incluído em um ou mais codificadores ou decodificadores, que podem ser integrados como parte de um CODEC combinado. Um aparelho incluindo o codificador de vídeo 28, decodificador de vídeo 48, codificador de áudio 26, decodificador de áudio 46, unidade de encapsulamento 30, unidade de recuperação 52 e/ou unidade de desencapsulamento 50 pode compreender um circuito integrado, um microprocessador e/ou um dispositivo de comunicação sem fio, tal como um telefone celular.
[0086] O dispositivo cliente 40, dispositivo servidor 60 e/ou dispositivo de preparação de conteúdo 20 pode ser configurado para operar de acordo com as técnicas da presente invenção. Para fins de exemplo, a presente invenção descreve essas técnicas com relação ao dispositivo cliente 40 e ao dispositivo servidor 60. No entanto, devese entender que o dispositivo de preparação de conteúdo 20 pode ser configurado para executar essas técnicas, em vez de (ou em adição a) o dispositivo de servidor 60.
[0087] A unidade de encapsulamento 30 pode formar unidades NAL compreendendo um cabeçalho que identifica um programa, ao qual a unidade NAL pertence, bem como uma. carga útil, por exemplo, dados de áudio, dados de vídeo ou dados que descrevem o fluxo de transporte ou programa ao qual a unidade NAL corresponde. Por exemplo, em H.264/AVC, uma unidade NAL inclui um cabeçalho de 1 byte e uma carga útil de tamanho variável. Uma unidade NAL incluindo dados de vídeo em sua carga útil pode compreender vários níveis de granularidade de dados de vídeo. Por exemplo, uma unidade NAL pode compreender um bloco de dados de vídeo, uma
Petição 870190095055, de 23/09/2019, pág. 45/94
41/68 pluralidade de blocos, uma fatia de dados de video ou uma imagem inteira de dados de video. A unidade de encapsulamento 30 pode receber dados de video codificados do codificador de vídeo 28 na forma de pacotes PES de fluxos elementares. A unidade de encapsulamento 30 pode associar cada fluxo elementar a um programa correspondente.
[0088] A unidade de encapsulamento 30 também pode compilar unidades de acesso de uma pluralidade de unidades MAL. Em geral, uma. unidade de acesso pode compreender uma ou mais unidades NAL para representar um quadro de dados de video, bem como dados de áudio correspondentes ao quadro quando esses dados de áudio estão disponíveis. Uma unidade de acesso geralmente inclui todas as unidades NAL para uma instância de tempo de saída, por exemplo, todos os dados de áudio e vídeo para uma instância de tempo. Por exemplo, se cada visualização tiver uma taxa de quadros de 20 quadros por segundo (fps), cada instância de tempo poderá corresponder a um intervalo de tempo de 0,05 segundos. Durante esse intervalo de tempo, os quadros específicos para todas as visualizações da mesma unidade de acesso (a mesma instância de tempo) podem ser renderizados simultaneamente. Em um exemplo, uma unidade de acesso pode compreender uma. imagem codificada em uma instância de tempo, que pode ser apresentada como· uma imagem codificada primária.
[0089] Por conseguinte, uma unidade de acesso pode compreender todos os quadros de áudio e vídeo de uma instância temporal comum, por exemplo, todas as visualizações correspondentes a um tempo X. Esta invenção também. se refere a uma imagem codificada de uma
Petição 870190095055, de 23/09/2019, pág. 46/94
42/68 visualização particular como um. componente de visualização. Ou seja, um. componente de visualização pode compreender uma imagem (ou quadro) codificada para uma visualização particular em um momento específico. 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 das unidades de acesso não precisa necessariamente ser a mesma que a ordem de saída, ou exibição.
[0090] Uma apresentação de mídia pode incluir uma. descrição de apresentação de mídia (MPD), que pode conter descrições de diferentes representações alternativas (por
| exemplo, | serviços de | V .1. Q θ O | com q | uaiidades difere | ntes) | e a. |
| descrição | pode inclui | .r, por | exemç | ) 1 o, i n f o rina. ç õ e s | de c | o dec, |
| um valor | de uerfil | e um ' | valor | de nível. Uma | MPD | é ura |
exemplo de um arquivo manifesto, tal como o arquivo manifesto 66. O dispositivo 40 pode recuperar a MPD de uma apresentação de mídia para. determinar como acessar fragmentos de filme de várias apresentações. Os fragmentos de filme podem ser localizados em caixas de fragmento de filme (caixas moof) de arquivos de vídeo.
[0091] O arquivo manifesto 66 (que pode compreender, por exemplo, uma MPD) pode anunciar a. disponibilidade de segmentos de representações 68. Ou seja, a MPD pode incluir informações indicando o tempo total em que um primeiro segmento de uma das representações 68 se torna disponível, assim como as informações indicando as durações de segmentos dentro das representações 68. Dessa maneira, a unidade de recuperação 52 do dispositivo cliente 40 pode determinar quando cada segmento está disponível,
Petição 870190095055, de 23/09/2019, pág. 47/94
43/68 com base no tempo de início, bem. como as durações dos segmentos anteriores a. um determinado segmento.
Γ0092] Após a unidade de encapsulamento 30 ter compilado unidades NAL e/ou unidades de acesso em um arquivo de vídeo com. base nos dados recebidos, a unidade de encapsulamento 30 passa o arquivo de vídeo para a interface de saída 32 para saída. Em alguns exemplos, a unidade de encapsulamento 30 pode armazenar o arquivo de vídeo localmente ou enviar o arquivo de vídeo para um servidor remoto através da interface de saída 32, em vez de enviar o arquivo de vídeo diretamente para o dispositivo cliente 40. A interface de saída 32 pode compreender, por exemplo, um transmissor, um transceptor, um dispositivo para gravar dados em um meio legível por computador, tal como, por exemplo, uma unidade óptica, uma unidade de mídia magnética (por exemplo, unidade de disquete), uma porta de barramento serial universal (USB) , uma interface de rede ou outra interface de saída. A interface de saída 32 envia o arquivo de vídeo para ura meio legível por computador, tal corão, por exemplo, um sinal de transmissão, um meio magnético, um meio óptico, uma memória, uma unidade flash ou outro meio legível por computador.
[0093] A interface de rede 54 pode receber uma. unidade NAL ou unidade de acesso através da rede 74 e prover a unidade NAL ou unidade de acesso à unidade de desencapsulamento 50, através da unidade de recuperação 52. A unidade de desencapsulamento 50 pode desenca.psu.lar elementos de um arquivo de vídeo em fluxos PES constituintes, desempacotar os fluxos PES para recuperar dados codificados, e enviar os dados codificados para o
Petição 870190095055, de 23/09/2019, pág. 48/94
44/68 decodificador de áudio 46 ou decodificador de video 48, dependendo de se os dados codificados fazem parte de um fluxo de áudio ou vídeo, por exemplo, conforme indicado pelos cabeçalhos de pacotes PES do fluxo. 0 decodificador de áudio 46 decodifica dados de áudio codificados e envia os dados de áudio decodificados para a. saída de áudio 42, enquanto o decodificador de vídeo 48 decodifica dados de vídeo codificados e envia os dados de vídeo decodificados, que podem incluir uma pluralidade de visualizações de um fluxo, para a saída de vídeo 44.
[0094] A Figura 2 é um diagrama de blocos ilustrando um conjunto exemplificative de componentes da unidade de recuperação 52 da Figura 1 em. maiores detalhes. Neste exemplo, a unidade de recuperação 52 inclui uma unidade de middleware eMBMS 100, cliente DASH 110 e aplicativo de mídia 112.
[0095] Neste exemplo, a unidade de middleware eMBMS 100 ainda inclui uma unidade de recepção eMBMS 10 6, memória cache 104 e unidade de servidor 102. Neste exemplo, a unidade de recepção eMBMS 106 é configurada para receber dados através de eMBMS, por exemplo, de acordo com a Entrega de Arquivos através de 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 eMBMS 106 pode receber arquivos através de broadcast, por exemplo, do dispositivo servidor 60, que pode atuar como um BM-SC.
[0096] Como a unidade de middleware eMBMS 100
Petição 870190095055, de 23/09/2019, pág. 49/94
45/68 recebe dados para arquivos, a unidade de middleware eMBMS pode armazenar os dados recebidos na memória cache 104. A memória cache 104 pode compreender um meio de armazenamento legível por computador, tal como memória flash, disco rígido, RAM ou qualquer outro meio de armazenamento □ QêQllclCíO « [0097] A unidade de servidor local 102 pode atuar como um servidor para cliente DASH 110. Por exemplo, a unidade de servidor local 102 pode fornecer um. arquivo MPD ou outro arquivo manifesto para o cliente DASH 110. A unidade de servidor local 102 pode anunciar tempos de disponibilidade para os segmentos no arquivo MPD, bem como hiperlinks a partir dos quais os segmentos podem, ser recuperados. Esses hiperlinks podem usar um prefixo de endereço de host local correspondente a um dispositivo cliente 40 (por exemplo, 127.0.0.1 para IPv4). Dessa maneira, o cliente DASH 110 pode solicitar segmentos da unidade de servidor local 102 usando requisições HTTP GET ou GET parcial. Por exemplo, para um segmento disponível no link http://127.0.0.l/repl/seg3, o cliente DASH 110 pode construir uma requisição HTTP GET que inclui uma requisição para, http://127.0.0.l/repl/seg3, e submeter a. requisição para a. unidade de servidor local 102. A unidade de servidor local 102 pode recuperar os dados solicitados da memória cache 104 e fornecer os dados ao cliente DASH 110 em resposta a. essas requisições.
[0098] De acordo com as técnicas da presente invenção, a unidade de encapsulamento 30 pode sinalizar, e a unidade de recuperação 52 pode receber, informações importantes de vídeo relacionadas a qualquer um ou todos os
Petição 870190095055, de 23/09/2019, pág. 50/94
46/68 dados de vídeo armazenados usando um esquema restrito, video HDR/WCG, video VR/omnidirecional/360, vídeo em pacote de quadro e video com alterações de orientação de exibição, tal que informações importantes de vídeo possam ser acessadas de forma conveniente por clientes de aplicativo, tais como clientes DASH, para tomar decisões de rejeição/seleção/aceitação/requisição. Como observado acima, informações importantes de vídeo podem incluir informações que podem, ser usadas para seleção de conteúdo, por exemplo, seleção pela unidade de recuperação 52 de uma faixa de vídeo ou uma parte da mesma para consumo.
[0099] As técnicas desta invenção podem superar os problemas mencionados acima. Por exemplo, para resolver o primeiro problema, a unidade de encapsulamento 30 e a unidade de recuperação 52 podem ser configuradas para usar um novo formato para o parâmetro '@codecs'f em que a indicação do uso de um. esquema restrito é incluída. Em. um. exemplo, um valor do parâmetro '^codecs' é definido da. seguinte maneira, tal que todas as informações consideradas importantes para o vídeo sejam incluídas no parâmetro 'codecs'. Neste exemplo, um primeiro elemento do parâmetro '^codecs' é o código tipo de entrada de amostra de uma faixa usando um esquema restrito (ou seja, uma. faixa armazena dados de mídia, tais como dados de vídeo, de acordo com um esquema restrito), por exemplo, 'resv'- Neste exemplo, o segundo elemento é o código tipo de esquema restrito, por exemplo, 'stvi' para vídeo em pacote de quadro e 'odvd' para vídeo omnidirecional.
[0100] Alternativamente, para vídeo omnidirecional, o segundo elemento é 'povd' para vídeo
Petição 870190095055, de 23/09/2019, pág. 51/94
47/68 omnidirecional projetado ou 'fovd' para vídeo omnidirecional olho de peixe. Alternativamente, para video omnidirecional projetado, o segundo elemento indica o tipo de projeção, por exemplo, 'erp’ para a projeção equirretangular ou 'cmp’ para a projeção em mapa cúbico.
[0101] Mais informações, incluindo detalhes importantes do tipo particular de esquema restrito, podem ser incluídas nos elementos subsequentes do arquivo manifesto. Por exemplo, se o segundo elemento for 'odvd', o terceiro elemento existe e é 'povd’ para video omnidirecional projetado ou 'fovd' para vídeo omnidirecional olho de peixe. Alternativamente, se o segundo elemento for 'odvd' e o terceiro elemento for 'povd.', o quarto elemento existe e indica o tipo de projeção, por exemplo, 'erp’ para a projeção equirretangular ou 'cmp' para a projeção em mapa cúbico. Por exemplo, os quatro elementos iniciais de um valor do parâmetro 'codecs’ de um vídeo omnidirecional projetado equirretangular seriam resv.odvd.povd.erp.
[0102] Os elementos acima podem ainda ser seguidos pelos elementos usuais de um valor dos parâmetros 'codecs’, conforme definido na cláusula E da ISO/IEC 1449615. Por exemplo, um valor do parâmetro 'codecs*' de um vídeo omnidirecional projetado equirretangular compatível com HEVC, progressivo, não compactado, Perfil Principal, Camada Principal e Nível 3.1 pode ser resv.odvd.povd.erp. heví.1.6.L93 . B0 .
[0103] Dessa maneira, a unidade de encapsulamento 30 pode sinalizar, e a unidade de recuperação 52 pode receber, qualquer um ou todos os valores 'resv’, 'stvid ,
Petição 870190095055, de 23/09/2019, pág. 52/94
48/68 'odvd' , 'povd', 'fovd', 'erp' ou 'cmp' como parte do parâmetro '^codecs', como discutido acima, por exemplo, dentro do arquivo manifesto 66. Além disso, a unidade de recuperação 52 pode determinar uma das representações 68 para recuperar, com base nos valores para o parâmetro Pcodecs sinalizados no arquivo manifesto 66 para representações 68, bem como recursos do decodificador de video 48.
[0104] Em um. segundo exemplo alternativo, um valor do parâmetro 'codecs' é definido da. seguinte forma, tal que algumas das informações consideradas importantes para o video sejam incluídas no parâmetro 'codecs', enquanto mais detalhes das informações consideradas importantes para, o vídeo são incluídos em um parâmetro tipo MIME diferente. Neste exemplo, o primeiro elemento do parâmetro C°codecs é o código tipo de entrada de amostra de uma faixa usando um esquema restrito, isto é, 'resv'. Neste exemplo, o segundo elemento pode ser o código tipo de esquema restrito, por exemplo, 'stvi' para vídeo em pacote de quadro e 'odvd' para vídeo omnidirecional. Alternativamente, para vídeo omnidirecional, o segundo elemento pode ser 'povd' para vídeo omnidirecional projetado ou 'fovd' para vídeo omnidirecional olho de peixe.
[0105] Os dois elementos acima podem ainda ser seguidos pelos elementos usuais de um valor dos parâmetros 'codecs', conforme definido na cláusula E da ISO/IEC 1449615. Por exemplo, um valor do parâmetro 'codecs' de um vídeo omnidirecional projetado equirretangular compatível com HEVC, progressivo, não compactado, Perfil Principal, Camada
Petição 870190095055, de 23/09/2019, pág. 53/94
49/68
Principal e Nivel 3.1 pode
Aiternativamente, um valor aciraa pode ser
Alternativamente, um valor :er resv.odvd.hevl.1.6.L93.BO. do parâmetro 'codecs' do video resv.povd.hevl.1.6,L93,B0.
do parâmetro 'codecs'' do video acima pode ser resv.erp.hevl.1.6.L93.B(
0106] Além do novo formato do parâmetro 'codecs' discutido aciraa, novos parâmetros tipo MIME opcionais poderá ser usados, os quais contêm mais detalhes do tipo particular de esquema restrito. O formato desses parâmetros tipo MIME opcionais é semelhante ao parâmetro 'codecs', ou seja, eles podem ser um valor único ou uma lista de valores separados por vírgula, em que cada valor na lista separada por vírgulas inclui um ou mais elementos separados por pontos (por exemplo, delimitado por ponto), e o espaço para nome de cada elemento pode ser determinado pelo elemento precedente. Como exemplo, um parâmetro tipo MIME opcional 'odvdinfo' pode conter mais detalhes de vídeo omnidirecional. De acordo com este exemplo, para um valor de 'odvdinfo' , o primeiro elemento pode ser ’’povd*' para vídeo omnidirecional projetado ou 'fovd' parat vídeo omnidirecional olho de peixe e, no primeiro caso de 'povd', o segundo elemento existe e indica o tipo de projeção, por exemplo, 'erp' para, a projeção equirretangular ou 'cmp' para a projeção em mapa cúbico. Mais elementos podem ser adicionados parat conter mais informações. Como alternativa, como outro exemplo, um parâmetro tipo MIME opcional 'fpvdinfo' pode conter mais detalhes de vídeo em pacote de quadro. Por exemplo, 'fpvdinfo' pode incluir elementos correspondentes stereo scheme e stereo indication type, conforme definido na. cláusula 8.15.4.2 da especificação
Petição 870190095055, de 23/09/2019, pág. 54/94
50/68
ISOBMFF.
[0107] Como outro exemplo, para resolver o segundo problema (que pode ser realizado em combinação com qualquer uma das técnicas acima para resolver o primeiro problema), a unidade de encapsulamento 30 e a unidade de recuperação 52 podem ser configuradas para, usar um novo tipo de esquema restrito que indica que uma faixa de uma representação transporta dados de video com alterações de orientação de exibição. Por exemplo, um código de 4 caracteres 'vdocd pode indicar que uma faixa correspondente transporta video com alterações de orientação de exibição.
[0108] Em um exemplo, nenhuma informação adicional é fornecida com relação às alterações de orientação de exibição, e uma. SchemelnformationBox pode estar ausente em uma RestrictedSchemelnfoBox. Em outra a11 e r n ativa, se uma ou ambas de rotação e inversão e ainda indicada uma caixa.
contida
Π8
SchemelnformationBox. Essa nova caixa pode incluir, por exemplo, um campo display orientation change type, com o valor que ambas rotação e inversão se aplicam, indicando que apenas rotação se aplica e denominado indicando o valor 1 o valor 2 indicando que apenas inversão se aplica. Assim, a. unidade de encapsulamento 30 pode definir o valor do campo display orientation change type com base em se uma faixa correspondente inclui uma ou ambas de rotação e/ou inversão, e a unidade de recuperação 52 pode determinar se uma faixa de uma das representações 68 inclui alterações de orientação de exibição, e se positivo, se as alterações incluem uma ou ambas de rotação e/ou inversão, a partir do
Petição 870190095055, de 23/09/2019, pág. 55/94
51/68
| [03 | . 0 9] Além | disso, o novo | formato pare | |
| parâmetro 'ο | odecs', co | n f o rme defini do | acima, também | pode |
| ser aplicado | . Por exeim | alo, um valor do | parâmetro 'cod | scs! |
| de vídeo com | orientação | de alteração de | exibição compat | ível |
com HEVC, progressivo, não compactada, Perfil Principal, Camada Principal e Nível 3.1 pode ser resv.vdoc.hevl.1.6.L93.BO. Da mesma forma, como em algumas alternativas dos exemplos acima, algumas informações adicionais, tais como display orientation change type, podem ser incluídas em um terceiro elemento de um valor do parâmetro 'codecs', e os elementos restantes podem ser podem ser puxados para baixo em ordem por um elemento.
[0110] Como outro exemplo, para resolver o terceiro problema (que pode ser realizado em combinação com qualquer uma das técnicas acima para resolver o primeiro problema e/ou técnicas acima para resolver o segundo problema), a unidade de encapsulamento 30 e a unidade de recuperação 52 podem ser configuradas para usar um parâmetro tipo MIME opcional 'hdrinfof, que pode conter informações importantes de vídeo HDR/WCG. O formato desses parâmetros tipo MIME opcionais pode ser um valor único ou uma lista de valores separados por vírgula (por exemplo, delimitados por ponto), em que cada valor inclui um ou mais elementos separados por pontos. Por exemplo, um valor do parâmetro 'hdrinfo' pode conter quatro campos, na forma de elmentl.elment2.elmentS.elmentí, em que os quatro elementos 1 a 4 podem ser representações hexadecimals dos campos colour primaries, transfer characteristics,
Petição 870190095055, de 23/09/2019, pág. 56/94
52/68 matrix coeffs e full range flag, respectivamente, conforme definido na cláusula 12.1.5 da. especificação ISOBMFF.
[0111] A Figura 3 é um diagrama conceituai ilustrando elementos de conteúdo multimídia exemplificativo 120. 0 conteúdo multimídia 120 pode corresponder ao conteúdo multimídia 64 (Figura 1) ou outro conteúdo multimídia armazenado no meio de armazenamento 62. No exemplo da Figura 3, o conteúdo multimídia 120 inclui descrição de apresentação de mídia (MPD) 122 e uma pluralidade de representações 124A-124N (representações 124) . A representação 124A inclui dados de cabeçalho opcionais 126 e segmentos 128A-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 filme em cada uma das representações 124 por questão de conveniência. Em alguns exemplos, pode haver números diferentes de fragmentos de filme entre as representações 124 .
| [0112] A MPD | 122 | pode compreender uma | estr | utura | |
| de | dados separada das | repr | esentações 124. A MPD | 122 | pode |
| cor | responder ao arquive | j man | ifesto 66 da Figura. 1. | Da | me sma |
forma, as representações 124 podem. corresponder às representações 68 da Figura 2. Em geral, a MPD 122 pode incluir dados que geralmente descrevem características de representações 124, tais como características de codificação e renderização, conjuntos de adaptação, um perfil ao qual a MPD 122 corresponde, informações sobre o tipo de texto, informações sobre o ângulo da câmera, informações sobre classificação, informações sobre modo
Petição 870190095055, de 23/09/2019, pág. 57/94
53/68 truque (por exemplo, informações indicativas de representações que incluem subsequências temporais) e/ou informações para recuperação de períodos remotos (por exemplo, para inserção direcionada de anúncios no conteúdo de mídia durante a reprodução).
[0113] Os dados de cabeçalho 126, quando presentes, podem descrever características dos segmentos
| 12 8, | P | or exemplo, | localizaçõe | :S temporais | de | pontos de |
| 3 C Θ S 8 | o | aleatórios | (RAPs, també | m referidos | como | pontos de |
| ô. C Θ S S | o | de fluxo í | (SAPs)), que | dos segment | c Ί ‘ | 28 incluem |
| ponto | 3 | de acesso | aleatórios, | deslocamento: | byte para | |
| ponto | c; | de acesso | aleatórios | dentro de | s e gme n t o s 12 8, |
localizadores uniformes de retorno (URLs) de segmentos 128 ou outros aspectos de segmentos 128. Os dados do cabeçalho 130, quando presentes, podem descrever características semelnantes para segmentos ±32. Adicionalmente ou alternativamente, essas características podem ser totalmente incluídas dentro da. MPD 122.
[0114] Os segmentos 128, 132 incluem uma ou mais amostras de vídeo codificadas, cada uma das quais pode incluir quadros ou fatias de dados de vídeo. Cada uma das amostras de vídeo codificadas dos segmentos 128 pode ter características semelhantes, por exemplo, altura, largura e requisitos de largura de banda. Essas características podem ser descritas pelos dados da MPD 122, embora esses dados
| não sejam | ilustrados no exemplo | da. Fig | ura 3 . | A MPD 122 pode |
| incluir cí | iracterísticas como as | des cr | 11 a s n a | E s p e c i f i c a ç ã o |
| 3GPP, com | a adição de qualquer | uma ou | todas | as informações |
sinalizadas descritas nesta invenção.
[0115] Cada um dos segmentos 128, 132 pode ser
Petição 870190095055, de 23/09/2019, pág. 58/94
54/68 associado a um único localizador de recurso uniforme (URL). Assim, cada um. dos segmentos 12 8, 132 pode ser recuperado de forma independente usando um protocolo de rede de streaming, tal como DASH. Dessa maneira, um dispositivo de destino, tal como o dispositivo cliente 40, pode usar uma. requisição HTTP GET para, recuperar segmentos 128 ou 132. Em alguns exemplos, o dispositivo cliente 40 pode usar requisições HTTP GET parcial para recuperar faixas de byte especificas dos segmentos 128 ou 132.
[0116] De acordo com. as técnicas da presente invenção, a MPD 122 pode incluir qualquer uma ou todas as várias informações tipo MIME exemplificativas discutidas acima. Por exemplo, a MPD 122 pode incluir um parâmetro
| Pcodecs, conforme discutido | a c i ma, que po d.e | indicar, por |
| exemplo, um código tipo de e | ntrada de amostra | de uma faixa |
| usando um esquema restrito | , um código tipo | de esquema |
| restrito e informações adiei | onais, por exemplo | , para vídeo |
| omnidirecional, tipos de | projeção ou | semelhantes. |
Adicionalmente ou alternativamente, a MPD 122 pode incluir informações indicando se as alterações de orientação de exibição são aplicáveis a uma das representações 124A-124N e, se positivo, um tipo de alteração de orientação de exibição (por exemplo, uma ou ambas de alteração e/ou inversão). Adicionalmente ou alternativamente, as informações de alteração de orientação de exibição podem ser fornecidas nos dados de cabeçalho 12 6, 130 e/ou dados de cabeçalho de qualquer um ou todos os segmentos 128, 132. Adicionalmente ou alternativamente, a MPD 122, dados de cabeçalho 126, 130 e/ou dados de cabeçalho de qualquer um ou todos os segmentos 128, 132 podem, conter informações
Petição 870190095055, de 23/09/2019, pág. 59/94
55/68 importantes do vídeo HDR/WCG, conforme discutido acima.
[0117] A Figura 4 é um diagrama de blocos ilustrando elementos de um arquivo de vídeo exemplificativo 150, que pode corresponder a um segmento de uma representação, tal como um dos segmentos 114, 124 da Figura 3. Cada um. dos segmentos 128, 132 pode incluir dados que são substancialmente compatíveis cora o arranjo de dados ilustrado no exemplo da Figura 4. Pode-se dizer que o arquivo de vídeo 150 encapsula um. segmento. Como descrito acima, os arquivos de vídeo de acordo com o formato de arquivo de mídia base ISO e suas extensões armazenam dados em uma série de objetos, denominados caixas. No exemplo da Figura 4, o arquivo de vídeo 150 inclui a caixa de tipo de arquivo (FTYP) 152, caixa, de filme (MOOV) 154, caixas de índice de segmento (sidx) 162, caixas de fragmento de filme (MOOF) 164 e caixa de acesso aleatório de fragmentos de filme (MFRA) 166. Embora a Figura 4 represente um exemplo de arquivo de vídeo, deve-se entender que outros arquivos de mídia podem incluir outros tipos de dados de mídia (por exemplo, dados de áudio, dados de texto programado ou semelhantes) estruturados de maneira semelhante aos dados de arquivo de vídeo 150, de acordo com. o formato de arquivo de mídia base ISO e suas extensões.
[0118] A caixa de tipo de arquivo (FTYP) 152 geralmente descreve um tipo de arquivo para o arquivo de vídeo 150. A caixa de tipo de arquivo 152 pode incluir dados que identificam uma especificação que descreve uma melhor utilização para o arquivo de vídeo 150. A caixa de tipo de arquivo 152 pode, alternativamente, ser colocada antes da caixa MOOV 154, caixas de fragmento de filme 164
Petição 870190095055, de 23/09/2019, pág. 60/94
56/68 [0119] Ent alguns exemplos, um segmento, tal como o arquivo de video 150, pode incluir uma caixa de atualização de MPD (não mostrada) antes da caixa FTYP 152. A caixa de atualização de MPD pode incluir informações indicando que uma. MPD correspondente a uma representação incluindo o arquivo de video 150 deve ser atualizada, juntamente com 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 outro exemplo, a caixa de atualização de MPD pode incluir dados para atualizar a MPD. Em alguns exemplos, a caixa de atualização de MPD pode seguir imediatamente uma caixa de tipo de segmento (STYP) (não mostrada) do arquivo de video 150, em que a caixa STYP pode definir um tipo de segmento para o arquivo de video 150. A Figura 7, discutida em. maiores detalhes abaixo, fornece informações adicionais com. respeito à. caixa de atualização de MPD.
[0120] A caixa MOOV 154, no exemplo da Figura 4, inclui a caixa de cabeçalho de filme (MVHD) 156, caixa de faixa (TRAK) 158 e uma ou mais caixas de extensão de filme
| (MVEX) 160. Em. geral, | a caixa | MVHD 156 pode descrever | 3 S |
| Q 31? 3 Q t. Θ JC 1. S L .I. Q 3 S Cl Θ .T? 3 _I | .3 dO 3Γ | quivo de video 150. | Por |
| exemplo, a caixa MVHD | 156 pode | incluir dados que descre | vem |
| quando o arquivo de | video 150 | foi originalmente cria | CIO f |
quando o arquivo de video 150 foi modi ficado pela última, vez, 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 geralmente descrevem o arquivo de video 150 .
Petição 870190095055, de 23/09/2019, pág. 61/94
57/68 [0121] A. caixa TRAK 158 pode incluir dados para uma faixa de arquivo de vídeo 150. A caixa TRAK 158 pode incluir uma caixa de cabeçalho de faixa (TKHD) que descreve características da faixa correspondente a uma caixa TRAK 158. Em alguns exemplos, a caixa TRAK 158 pode incluir imagens de vídeo codificadas, enquanto, em outros exemplos, as imagens de vídeo· codificadas da faixa podem ser incluídas nos fragmentos de filme 164, que podem ser referenciados pelos dados da caixa TRAK 158 e/ou caixas s i d.x 162.
[0122] Em alguns exemplos, o arquivo de vídeo 150 pode incluir mais de uma faixa. Por conseguinte, a caixa MOOV 154 pode incluir um. número de caixas TRAK igual ao número de faixas no arquivo de vídeo 150. A caixa. TRAK 158 pode descrever características de uma faixa correspondente de arquivo de vídeo 150. Por exemplo, a caixa TRAK 158 pode descrever informações espaciais e/ou temporais para a faixa
| correspondente. Uma | c a 2. x | a TRAK semelhante à | caixa TRAK 158 |
| da caixa MOOV 154 | pode | descrever caracterí | sticas de uma |
| faixa de conjunto | de | parâmetros, quando | a unidade de |
| encapsulamento 30 ( | Figur | a 3) inclui uma fail | Ka de conjunto |
| de parâmetros em um | arqu: | Lvo de vídeo, tal com | lO o arquivo de |
vídeo 150. A unidade de encapsulamento 30 pode sinalizar a. presença de mensagens SEI de nível de sequência na faixa de conjunto de parâmetros na caixa TRAK que descreve a faixa de conjunto de parâmetros.
[0123] A.s caixas MVEX 160 podem. descrever características dos fragmentos de filme correspondentes 164, por exemplo, para sinalizar que o arquivo de vídeo 150 inclui fragmentos de filme 164, além, de dados de vídeo
Petição 870190095055, de 23/09/2019, pág. 62/94
58/68 incluídos na caixa MOOV 154, se houver. No contexto de dados de vídeo de streaming, imagens de vídeo codificadas podem ser incluídas nos fragmentos de filme 164 em vez de na caixa MOOV 154. Por conseguinte, todas as amostras de vídeo codificadas podem ser incluídas nos fragmentos de filme 164, em vez de na caixa MOOV 154.
[0124] A caixa MOOV 154 pode incluir um número de caixas MVEX 160 igual ao número de fragmentos de filme 164 no arquivo de vídeo 150. Cada uma das caixas MVEX 160 pode descrever características de um dos fragmentos de filme correspondentes 164. Por exemplo, cada caixa MVEX pode incluir uma caixa de cabeçalho de extensão de filme (MEHD) que descreve uma duração temporal para um dos fragmentos de filme correspondentes 164.
[0125] Como observado acima, a unidade de encapsulamento 30 pode armazenar um conjunto de dados de sequência em uma amostra de vídeo que não incluir dados de vídeo codificados reais. Uma amostra, de vídeo geralmente pode corresponder a uma unidade de acesso, que é uma representação de uma imagem codificada em uma instância de tempo específica. No contexto da AVC, a imagem codificada inclui uma ou mais unidades VCL NAL que contêm as informações para construir todos os pixels da unidade de acesso e outras unidades NAL não VCL associadas, tais como mensagens SEI. Por conseguinte, a unidade de encapsulamento 30 pode incluir um conjunto de dados de sequência, que pode incluir mensagens SEI de nível da sequência, em um dos fragmentos de filme 164. A unidade de encapsulamento 30 ainda pode sinalizar a presença de um conjunto de dados de sequência e/ou mensagens SEI de nível de sequência como
Petição 870190095055, de 23/09/2019, pág. 63/94
59/68 estando presentes em um dos fragmentos de filme 164 dentro de uma das caixas MVEX 160 correspondentes a um dos fragmentos de filme 164.
[0126] As caixas SIDX 162 são elementos opcionais de arquivo de video 150. Ou seja, os arquivos de video compatíveis com o formato de arquivo 3GPP, ou outros formatos de arquivo desse tipo, não necessariamente incluem caixas SIDX 162. De acordo com o exemplo do formato de arquivo 3GPP, uma caixa SIDX pode ser usada para identificar um subsegmento de um segmento (por exemplo, um segmento contido no arquivo de video 150) . O formato de arquivo 3GPP define um subsegmento como um conjunto independente de uma ou mais caixas de fragmento de filme consecutivas com Caixa(s) de Dados de Mídia, e uma Caixa de Dados de Mídia correspondentes contendo dados referenciados por uma Caixa de Fragmento de Filme deve seguir a caixa de Fragmento de Filme e preceder a próxima, caixa, de Fragmento de Filme que contém, informações sobre a mesma, faixa. O formato de arquivo 3GPP também indica que uma caixa de SIDX contém uma sequência de referências a subsegmentos do (sub)segmento documentado pela caixa. Os subsegmentos referenciados são contíguos no tempo de apresentação. Da mesma forma, os bytes referidos por uma caixa, de índice de Segmento são sempre contíguos dentro do segmento. O tamanho referenciado fornece a contagem do número de bytes no material referenciado.
[0127] A.s caixas SIDX 162 geralmente fornecem informações representativas de um ou mais subsegmentos de um segmento incluído no arquivo de vídeo 150. Por exemplo, essas informações podem, incluir tempos de reprodução nos
Petição 870190095055, de 23/09/2019, pág. 64/94
60/68 quais os subsegmentos começam e/ou terminam, deslocamentos de bytes para os subsegmentos, se os subsegmentos incluem (por exemplo, começam com) um ponto de acesso de fluxo (SAP) , um tipo para o SAP (por exemplo, se o SAP é uma imagem de atualização de decodificador instantânea (IDR), uma imagem de acesso aleatório limpo (CRA), uma imagem de acesso de link quebrado (BLA), ou semelhantes), uma posição do SAP (em termos de tempo de reprodução e/ou deslocamento de bytes) no subsegmento, e semelhantes.
[0128] Os fragmentos de filme 164 podem incluir uma ou mais imagens de vídeo codificadas. Em alguns exemplos, os fragmentos de filme 164 podem incluir um ou mais grupos de imagens (GOPs), cada um dos quais pode incluir um número de imagens de video codificadas, por exemplo, quadros ou imagens. Além disso, como 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 MFHD pode descrever características do fragmento de filme correspondente, tal como um número de sequência para o fragmento de filme. Os fragmentos de filme 164 podem ser incluídos na ordem do número de sequência no arquivo de video 150.
[0129] A caixa MFRA 166 pode descrever pontos de acesso aleatórios dentro dos fragmentos de filme 164 do arquivo de video 150. Isso pode ajudar na execução de modos de truque, tais como a realização de pesquisas em locais temporais específicos (isto é, tempos de reprodução) dentro de um segmento encapsulado pelo arquivo de vídeo 150. A
Petição 870190095055, de 23/09/2019, pág. 65/94
61/68 caixa MFRA 166 é geralmente opcional e não precisa ser incluída em arquivos de vídeo, em alguns exemplos. Da mesma forma, um dispositivo cliente, tal como o dispositivo cliente 40, não precisa necessariamente referenciar a caixa MFRA 166 para decodificar e exibir corretamente os dados de vídeo do arquivo de vídeo 150. .A caixa MFRA 166 pode incluir um número de caixas de acesso aleatório de fragmentos de faixa (TFRA) (não mostradas) igual ao número de faixas do arquivo de vídeo 150 ou, em alguns exemplos, igual ao número de faixas de mídia (por exemplo, faixas de não dica) do arquivo de video 150.
[0130] Em alguns exemplos, os fragmentos de filme 164 podem incluir um ou mais pontos de acesso de fluxo (SAPs) , tais como imagens IDR. Da mesma forma, a. caixa MFRA.
166 pode fornecer indicações de locais dentro do arquivo de vídeo 150 dos SAPs. Por conseguinte, umet subsequência temporal do arquivo de vídeo 150 pode ser formada a partir de SAPs do arquivo de video 150. A subsequência. temporal também pode incluir outras imagens, tais como quadros P e/ou quadros B que dependem de SAPs. Os quadros e/ou tatias dct subsequência temporal podem ser organizados dentro dos segmer
3.
da auencia : empo
-I / i. cà
Si /sequence a adamente no lerarquico dade sados na.
s u.o seque n c i a.
da invenção aixa poete incluir uma ca ix chemeI ionB e/ ou
Petição 870190095055, de 23/09/2019, pág. 66/94
62/68
RestrictedSchemelnfoBox) que indicam se uma ou ambas de alterações e/ou inversão são aplicadas a. dados de video incluídos nos fragmentos de filme 164, como discutido acima. Adicionalmente ou alternativamente, a caixa MOOV 154 pode conter informações importantes de vídeo HDR/WCG, conforme discutido acima.
[0132] Da mesma forma, os dados de vídeo de uma faixa de arquivo de vídeo 150 podem ser armazenados de acordo com. um. esquema restrito, tal como vídeo omnidirecional, vídeo em. pacote de quadro ou semelhantes. Um arquivo manifesto, tal como uma MPD, pode incluir dados indicando o esquema restrito para os dados de vídeo da faixa, conforme discutido acima.
[0133] A. Figura 5 é um fluxograma que ilustra um método exemplificativo de acordo com as técnicas da presente invenção. O método da Figura 5 é explicado como sendo executado pela unidade de recuperação 52 do dispositivo cliente 40 da Figura 1, embora deve-se compreender que outros dispositivos podem ser configurados para executar este ou um método semelhante.
[0134] Inicialmente, a unidade de recuperação 52 recupera um arquivo manifesto (180). O arquivo manifesto pode corresponder ao arquivo manifesto 66 da Figura 1. O arquivo manifesto pode ser, por exemplo, uma descrição de apresentação de mídia (MPD) . De acordo com as técnicas da presente invenção, o arquivo manifesto pode incluir dados que especificam um ou mais codecs para uma ou mais representações, por exemplo, uma ou mais das representações 68 da Figura 1.
[0135] A unidade de recuperação 52 pode, então,
Petição 870190095055, de 23/09/2019, pág. 67/94
63/68 extrair os dados que especificam os um ou mais codecs. Em. particular, de acordo com as técnicas da presente invenção, a unidade de recuperação 52 pode extrair um código tipo de entrada de amostra do arquivo manifesto (182) . 0 código tipo de entrada de amostra podem ser para uma faixa de uma das representações correspondentes ao arquivo manifesto. Como discutido acima, o código tipo de entrada de amostra pode compreender resv para indicar que a faixa armazena dados de vídeo usando um esquema restrito.
[0136] A unidade de recuperação 52 pode, então, extrair um código tipo de esquema restrito do arquivo manifesto (184) . Por exemplo, se os dados de vídeo da faixa forem armazenados usando um esquema de vídeo em pacote de quadro, a unidade de recuperação 52 pode extrair stvi do arquivo manifesto para a faixa, indicando que a faixa armazena dados de vídeo usando o esquema de vídeo em pacote de quadro. Como outro exemplo, a unidade de recuperação 52 pode determinar que os dados de video da. faixa são armazenados usando um esquema de video omnidirecional em resposta à extração de odvd do arquivo manifesto para a faixa. Ainda como outro exemplo, fovd pode indicar que os dados de vídeo da faixa são armazenados usando dados de vídeo omnidirecional olho de peixe, erp para um esquema de projeção equirretangular, ou cmp para um esquema de projeção em mapa cúbico.
[0137] Embora a Figura 5 ilustre um exemplo em que dois elementos são extraídos, deve-se compreender que a unidade de recuperação 52 pode extrair elementos adicionais, por exemplo, em um formato delimitado por ponto ou vírgula. Em. alguns exemplos, a unidade de recuperação 52
Petição 870190095055, de 23/09/2019, pág. 68/94
64/68 pode extrair um conjunto de valores para um ou mais parâmetros @codecs, em que os valores para os parâmetros @codecs podem ser respectivas listas de elementos delimitados por ponto. Por exemplo, a unidade de recuperação 52 pode extrair resv.odvd.povd.erp para uma faixa e determinar que resv indica que a faixa inclui dados de video armazenados usando ura esqueraa restrito, odvd indica que os dados de vídeo são dados de video
| omni | . d. .1. r e c .1. o n a 1, | povd indica que os dí | idos de | vídeo são |
| dadc | /s de vídeo | omni d i r e c ion.a 1 pro j e t ado, | e erp | indica, que |
| dados de | vídeo são dados de | vídeo | proj etado |
equirretangular .
[0138] Além disso, como discutido acima, a unidade de recuperação 52 pode extrair elementos adicionais de um parâmetro tipo MIME diferente do arquivo manifesto. O parâmetro tipo MIME pode ser, por exemplo, odvdinfo. Os elementos adicionais podem ser, por exemplo, povd, fovd, erp, cmp, ou semelhantes. Adicionalmente ou alternativaraente, o parâmetro tipo MIME pode ser fpvdinfo para especificar informações de video em pacote de quadro, tais como um esquema estéreo e/ou um tipo de indicação estéreo.
[0139] A unidade de recuperação 52 pode, então, recuperar dados de mídia usando os códigos extraídos (18 6) . Por exemplo, a unidade de recuperação 52 pode recuperar dados de vídeo de um esquema que é suportado, por exemplo, pelo decodificador de vídeo 48 e saída de vídeo 44 (Figura 1), e também evitar recuperar dados de vídeo de esquemas que não são suportados pelo decodif icador de vídeo 48 e saída de vídeo 44. Por exemplo, se o decodificador de vídeo
Petição 870190095055, de 23/09/2019, pág. 69/94
65/68 for capaz de decodificar, e a saída de video 44 for capaz de exibir, os dados de vídeo de um formato omnidirecional, a unidade de recuperação 52 pode pesquisar o arquivo manifesto para uma representação incluindo uma faixa armazenando dados de vídeo usando o esquema de vídeo omnidirecional, por exemplo, resv.odvd. Da mesma forma, se o decodificador de video 48 não for capaz de decodificar dados de vídeo em pacote de quadro, a unidade de recuperação 52 pode evitar recuperar dados de vídeo de uma faixa indicada como tendo resv.stvi para o parâmetro @codecs no arquivo manifesto.
[0140] Dessa maneira, o método da Figura 5 representa um exemplo de um. método incluindo recuperar um arquivo manifesto especificando dados para, pelo menos uma representação de uma apresentação de mídia, em que o arquivo manifesto inclui dados que especificam um ou mais codecs para a pelo menos uma representação, extrair, do arquivo manifesto, os dados que especificam os um ou mais codecs, incluindo extrair um primeiro elemento representando um código tipo de entrada de amostra de uma faixa da pelo menos uma representação, em que o primeiro elemento representa que a faixa inclui dados de vídeo armazenados usando um esquema restrito, e extrair um segundo elemento representando um código tipo de esquema restrito para o esquema restrito da faixa, e recuperar dados da. pelo menos uma representação com base no primeiro elemento e no segundo elemento.
[0141] Em um ou mais exemplos, as funções descritas podem ser implementadas em hardware, software, firmware ou qualquer combinação dos mesmos. Se
Petição 870190095055, de 23/09/2019, pág. 70/94
66/68 implementadas em software, as funções podem ser armazenadas em ou transmitidas como 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. Meio legível por computador pode incluir meio de armazenamento legível por computador, que corresponde a. um. meio tangível, tal como meio de armazenamento de dados ou meio de comunicação, incluindo qualquer meio que facilite a transferência de um programa de computador de um lugar para outro, por exemplo, de acordo com. um protocolo de comunicação. Desse modo, o meio legível por computador geralmente pode corresponder a (1) meio de armazenamento legível por computador tangível que é não transitório ou (2) um. meio de comunicação, tal como um sinal ou. onda portadora. G meio de armazenamento de dados pode ser qualquer meio disponível que possa ser acessado por um ou mais computadores ou um ou mais processadores para recuperar instruções, código e/ou estruturas de dados para implementação das técnicas descritas nesta divulgação. Um produto de programa de computador pode incluir um meio legível por computador.
[0142] A título de exemplo, e não de limitação, esses meios de armazenamento legíveis por computador podem, compreender RAM, ROM, EEPROM, CD-ROM ou. outro armazenamento em disco óptico, armazenamento em disco magnético ou outros dispositivos de armazenamento magnético, memória flash ou qualquer outro meio que possa ser usado para armazenar o código de programa desejado na forma de instruções ou estruturas de dados e que possa ser acessado por ura computador. Além disso, qualquer conexão é adequadamente denominada meio legível por computador. Por exemplo, se as
Petição 870190095055, de 23/09/2019, pág. 71/94
67/68 instruções forem transmitidas de um site, servidor ou outra fonte remota usando um cabo coaxial, cabo de fibra ótica, par trançado, linha de assinante digital (DSL) ou tecnologias sem fio, tais como infravermelho, rádio e micro-ondas, então, o cabo coaxial, cabo de fibra óptica, par trançado, DSL ou tecnologias sem fio, tais como infravermelho, rádio e micro-ondas, são incluídas na definição de meio. Deve-se entender, no entanto, que o meio de armazenamento legível por computador e o meio de armazenamento de dados não incluem. conexões, ondas portadoras, sinais ou outros meios transitórios, mas se referem a meios de armazenamento tangíveis e não transitórios. Disco (disk) e disco (disc), como aqui utilizados, incluem disco compacto (CD), disco laser, disco óptico, disco versátil digital (DVD), disquete e disco Bluray, em que os discos (disks) geralmente reproduzem dados magneticamente, enquanto os discos (discs) reproduzem dados opticamente com lasers. As combinações acima, também devem ser incluídas no escopo de meio legível por computador.
[0143] As instruções podem ser executadas por um ou mais processadores, tais como um ou mais processadores de sinal digital (DSPs), microprocessadores de uso geral, circuitos integrados de aplicação especifica (ASICs), matrizes lógicas prcgramáveis em campo (FPGAs) ou outro circuito de lógica discreta ou integrada equivalente. Por conseguinte, o termo processador, como aqui utilizado, pode se referir a qualquer uma da estrutura anterior ou qualquer outra estrutura adequada para a implementação das técnicas aqui descritas. Além disso, em alguns aspectos, a funcionalidade aqui descrita pode ser fornecida em módulos
Petição 870190095055, de 23/09/2019, pág. 72/94
68/68 de software e/ou hardware dedicados configurados para codificação e decodificação, ou incorporados em um codec combinado. Além disso, as técnicas poderiam ser totalmente implementadas em um ou mais circuitos ou elementos lógicos.
[0144] As técnicas desta invenção podem ser implementadas em uma ampla variedade de dispositivos ou aparelhos, incluindo um aparelho sem fio, um circuito integrado (IC) ou um conjunto de ICs (por exemplo, um chipset). Vários componentes, módulos ou unidades são descritos nesta invenção para enfatizar aspectos funcionais de dispositivos configurados para executar as técnicas divulgadas, mas requerem necessariamente a realização por diferentes unidades de hardware. Em vez disso, como descrito acima, várias unidades podem ser combinadas em uma unidade de hardware de codec ou fornecida por uma coleção de unidades de hardware interoperativas, incluindo um ou mais processadores, como descrito acima, em. conjunto com. software e/ou firmware adequados.
[0145] Vários exemplos foram descritos. Esses e outros exemplos estão dentro do escopo das reivindicações a seguir.
Claims (41)
- REIVINDICAÇÕES1. Método de recuperação de dados de mídia, o método compreendendo:recuperar um arquivo manifesto especificando dados para pelo menos uma representação de uma apresentação de mídia, em que o arquivo manifesto inclui dados que especificam um ou mais codecs para a pelo menos uma representação;extrair, do arquivo manifesto, os dados que especificam os um ou mais codecs, incluindo:extrair um primeiro elemento representando um código tipo de entrada de amostra de uma faixa da pelo menos uma representação, em que o primeiro elemento representa que a faixa inclui dados de vídeo armazenados usando um esquema restrito; e extrair um segundo elemento representando um código tipo de esquema restrito para o esquema restrito da faixa; e recuperar dados de mídia da pelo menos uma representação com base no primeiro elemento e no segundo elemento.
- 2. Método, de acordo com a reivindicação 1, em que extrair os dados que especificam os um ou mais codecs compreende:extrair um primeiro conjunto de valores para um ou mais parâmetros @codecs, em que os valores para os parâmetros @codecs compreendem respectivas listas de elementos delimitados por ponto incluindo o primeiro elemento e o segundo elemento; e extrair um segundo conjunto de valoresPetição 870190095055, de 23/09/2019, pág. 74/942/12 compreendendo informações adicionais para os parâmetros @codecs de um parâmetro tipo MIME diferente.
- 3. Método, de acordo com a reivindicação 2, em que as informações adicionais compreendem informações indicando um tipo particular de esquema restrito.
- 4. Método, de acordo com a reivindicação 2, em que o parâmetro tipo MIME diferente compreende 'odvdinfo' , e em que extrair o segundo conjunto de valores compreende extrair pelo menos um de 'povd', 'fovd', 'erp' ou 'cmp'.
- 5. Método, de acordo com a reivindicação 4, compreendendo ainda determinar que a faixa da pelo menos uma representação compreende dados de vídeo incluindo:dados de vídeo omnidirecional projetado quando o código tipo de esquema restrito compreende 'povd';dados de vídeo omnidirecional olho de peixe quando o código tipo de esquema restrito compreende 'fovd';dados de vídeo omnidirecional projetado equirretangular quando o código tipo de esquema restrito compreende 'erp'; ou dados de vídeo omnidirecional projetado em mapa cúbico quando o código tipo de esquema restrito compreende 'cmp'.
- 6. Método, de acordo com a reivindicação 2, em que as informações adicionais compreendem informações indicando um tipo particular de dados de vídeo em pacote de quadro.
- 7. Método, de acordo com a reivindicação 6, em que o parâmetro tipo MIME diferente compreende 'fpvdinfo'.
- 8. Método, de acordo com a reivindicação 6, em que o tipo particular de dados de vídeo em pacote de quadroPetição 870190095055, de 23/09/2019, pág. 75/943/12 compreende elementos correspondentes a stereo_scheme ou stereo_indication_type.
- 9. Método, de acordo com a reivindicação 1, compreendendo ainda:receber um ou mais valores para um parâmetro tipo MIME 'hdrinfo' para a faixa, os valores para o parâmetro tipo MIME incluindo informações para pelo menos um de dados de video de alta faixa dinâmica (HDR) ou ampla faixa de cores (WCG) para a faixa, em que recuperar os dados de mídia da pelo menos uma representação compreende recuperar dados de mídia da faixa com base nos valores para o parâmetro tipo MIME.
- 10. Método, de acordo com a reivindicação 9, em que os um ou mais valores são um valor único para o parâmetro tipo MIME 'hdrinfo'.
- 11. Método, de acordo com a reivindicação 9, em que os um ou mais valores são uma lista de valores separados por vírgula para o parâmetro tipo MIME 'hdrinfo', cada um dos valores na lista separados por vírgula compreendendo um único elemento ou uma lista de elementos separados por ponto.
- 12. Método, de acordo com a reivindicação 11, em que pelo menos um dos valores na lista separados por vírgula compreende uma lista de elementos separados por ponto, os elementos compreendendo representações hexadecimals de campos HDR ou WCG, incluindo colour_primaries, transfer_characteristics, matrix_coeffs e full_range_flag.
- 13. Método, de acordo com a reivindicação 1, em que o arquivo manifesto compreende uma descrição dePetição 870190095055, de 23/09/2019, pág. 76/944/12 apresentação de mídia (MPD) de streaming adaptativo dinâmico sobre HTTP (DASH).
- 14. Método, de acordo com a reivindicação 1, em que o arquivo manifesto especifica dados para uma pluralidade de representações incluindo a pelo menos uma representação, incluindo dados que especificam um ou mais codecs para cada uma da pluralidade de representações.
- 15. Método, de acordo com a reivindicação 14, compreendendo ainda selecionar a pelo menos uma representação em resposta à determinação de que um dispositivo cliente inclui um codec de vídeo compatível com o código tipo de entrada de amostra e o código tipo esquema.
- 16. Método, de acordo com a reivindicação 1, em que a representação compreende uma pluralidade de segmentos, cada um dos segmentos compreendendo um arquivo individualmente recuperável associado com um único localizador uniforme de recursos (URL).
- 17. Método, de acordo com a reivindicação 1, em que recuperar os dados de mídia da pelo menos uma representação compreende recuperar pelo menos um de um segmento da representação usando uma requisição HTTP GET ou um segmento parcial da representação usando uma requisição HTTP GET parcial.
- 18. Método, de acordo com a reivindicação 1, em que o código tipo de entrada de amostra compreende 'resv'.
- 19. Método, de acordo com a reivindicação 1, em que o código tipo de esquema restrito compreende pelo menos um de 'stvi', 'odvd', 'povd', 'fovd', 'erp' ou 'cmp'.
- 20. Método, de acordo com a reivindicação 19,Petição 870190095055, de 23/09/2019, pág. 77/945/12 compreendendo ainda determinar que a faixa da pelo menos uma representação compreende dados de vídeo incluindo:dados de vídeo em pacote de quadro quando o código tipo de esquema restrito compreende 'stvi';dados de vídeo omnidirecional quando o código tipo de esquema restrito compreende 'odvd';dados de vídeo omnidirecional projetado quando o código tipo de esquema restrito compreende 'povd';dados de vídeo omnidirecional olho de peixe quando o código tipo de esquema restrito compreende 'fovd';dados de vídeo omnidirecional projetado equirretangular quando o código tipo de esquema restrito compreende 'erp'; ou dados de vídeo omnidirecional projetado em mapa cúbico quando o código tipo de esquema restrito compreende 'cmp'.
- 21. Método, de acordo com a reivindicação 1, em que extrair os dados que especificam os um ou mais codecs ainda compreende, em resposta à determinação de que o código tipo de esquema restrito compreende 'odvd', extrair um terceiro elemento representando um tipo de dados de vídeo omnidirecional para a faixa.
- 22. Método, de acordo com a reivindicação 21, compreendendo ainda determinar que a faixa da pelo menos uma representação compreende dados de vídeo incluindo:dados de vídeo omnidirecional projetado quando o terceiro elemento compreende um valor de 'povd'; ou dados de vídeo omnidirecional olho de peixe quando o código tipo de esquema restrito compreende 'fovd'.
- 23. Método, de acordo com a reivindicação 21, emPetição 870190095055, de 23/09/2019, pág. 78/946/12 que extrair os dados que especificam os um ou mais codecs ainda compreende, em resposta à determinação de que o terceiro elemento compreende um valor de 'povd', extrair um quarto elemento que indica um tipo de projeção.
- 24. Método, de acordo com a reivindicação 23, compreendendo ainda, em resposta à determinação de que os dados de vídeo da faixa compreendem dados de vídeo omnidirecional projetado, determinar que os dados de vídeo omnidirecional projetado compreendem:uma projeção equirretangular quando o quarto elemento tem um valor de 'erp'; ou uma projeção em mapa cúbico quando o quarto elemento tem um valor de 'cmp'.
- 25. Método, de acordo com a reivindicação 1, em que extrair os dados que especificam os um ou mais codecs compreende extrair uma pluralidade de elementos após o primeiro elemento e o segundo elemento.
- 26. Método, de acordo com a reivindicação 1, em que extrair os dados que especificam os um ou mais codecs compreende extrair valores para um ou mais parâmetros @codecs, em que os valores para os parâmetros @codecs compreendem respectivas listas de elementos delimitados por ponto.
- 27. Método, de acordo com a reivindicação 1, compreendendo ainda extrair dados que especificam que a faixa inclui dados de vídeo com alterações de orientação de exibição, em que a faixa é incluída em um arquivo de mídia da pelo menos uma representação, e em que recuperar os dados de mídia da pelo menos uma representação compreende recuperar dados de mídia da faixa com base nos dados quePetição 870190095055, de 23/09/2019, pág. 79/947/12 especificam que a faixa inclui os dados de video com as alterações de orientação de exibição.
- 28. Método, de acordo com a reivindicação 27 que os dados que especificam que a faixa inclui os dados de video com as alterações de orientação de exibição compreendem um valor 'vdoc' para um tipo de esquema restrito para a faixa.
- 29. Método, de acordo com a reivindicação 27 que extrair compreende extrair o valor para o tipo de esquema restrito de uma RestrictedSchemelnfoBox para a faixa.
- 30. Método de acordo com a reivindicação 27 compreendendo ainda, em resposta à determinação de que a faixa inclui os dados de video com as alterações de orientação de exibição, extrair dados que indicam se as alterações de orientação de exibição incluem uma ou ambas de rotação ou inversão de uma SchemelnformationBox.
- 31. Método, de acordo com a reivindicação 30, compreendendo ainda:determinar que as alterações de orientação de exibição incluem ambas rotação e inversão quando um SchemelnformationBox tem um valor de 0;determinar que as alterações de orientação de exibição incluem rotação quando um SchemelnformationBox tem um valor de 1; ou determinar que as alterações de orientação de exibição incluem inversão quando um SchemelnformationBox tem um valor de 2.
- 32. Dispositivo para recuperação de dados de mídia, o dispositivo compreendendo:Petição 870190095055, de 23/09/2019, pág. 80/948/12 uma memória configurada para armazenar dados de mídia; e um ou mais processadores implementados em circuito e configurados para:recuperar um arquivo manifesto especificando dados para pelo menos uma representação de uma apresentação de mídia, em que o arquivo manifesto inclui dados que especificam um ou mais codecs para a pelo menos uma representação;extrair, do arquivo manifesto, os dados que especificam os um ou mais codecs, os dados incluindo um primeiro elemento representando um código tipo de entrada de amostra de uma faixa da pelo menos uma representação, em que o primeiro elemento representa que a faixa inclui dados de vídeo armazenados usando um esquema restrito, e um segundo elemento representando um código tipo de esquema restrito para o esquema restrito da faixa; e recuperar os dados de mídia da pelo menos uma representação com base no primeiro elemento e no segundo elemento.
- 33. Dispositivo, de acordo com a reivindicação 32, em que, para extrair os dados que especificam os um ou mais codecs, os um ou mais processadores são configurados para:
extrair um primeiro conjunto de valores para um ou mais parâmetros @codecs, em que os valores para os parâmetros @codecs compreendem respectivas listas de elementos delimitados por ponto; e extrair um segundo conjunto de valores compreendendo informações adicionais para os parâmetrosPetição 870190095055, de 23/09/2019, pág. 81/949/12 @codecs de um parâmetro tipo MIME diferente. - 34. Dispositivo, de acordo com a reivindicação 33, em que o parâmetro tipo MIME diferente compreende 'odvdinfo' , e em que extrair o segundo conjunto de valores compreende extrair pelo menos um de 'povd', 'fovd', 'erp' ou 'cmp' , e em que os um ou mais processadores são ainda configurados para determinar que a faixa da pelo menos uma representação compreende dados de video incluindo:dados de video omnidirecional projetado quando o código tipo de esquema restrito compreende 'povd';dados de video omnidirecional olho de peixe quando o código tipo de esquema restrito compreende 'fovd';dados de video omnidirecional projetado equirretangular quando o código tipo de esquema restrito compreende 'erp'; ou dados de video omnidirecional projetado em mapa cúbico quando o código tipo de esquema restrito compreende 'cmp'.
- 35. Dispositivo, de acordo com a reivindicação 33, em que as informações adicionais compreendem informações indicando um tipo particular de dados de video em pacote de quadro, em que o parâmetro tipo MIME diferente compreende 'fpvdinfo', e em que o tipo particular de dados de video em pacote de quadro compreende elementos correspondentes a stereo_scheme e stereo_indication_type.
- 36. Dispositivo, de acordo com a reivindicação 32, em que os um ou mais processadores são ainda configurados para receber um ou mais valores para um parâmetro tipo MIME 'hdrinfo' para a faixa, os valores para o parâmetro tipo MIME incluindo informações para pelo menosPetição 870190095055, de 23/09/2019, pág. 82/9410/12 um de dados de video de alta faixa dinâmica (HDR) ou ampla faixa de cores (WCG) para a faixa, em que, para recuperar os dados de mídia da pelo menos uma representação, os um ou mais processadores são configurados para recuperar dados de mídia da faixa com base nos valores para o parâmetro tipo MIME.
- 37. Dispositivo, de acordo com a reivindicação 36, em que os um ou mais valores compreendem um de um único valor para o parâmetro tipo MIME 'hdrinfo' ou uma lista de valores separados por vírgula para o parâmetro tipo MIME 'hdrinfo', cada um dos valores na lista separados por vírgula compreendendo um único elemento ou uma lista de elementos separados por ponto.
- 38. Dispositivo, de acordo com a reivindicação 32, em que o arquivo manifesto compreende uma descrição de apresentação de mídia (MPD) de streaming adaptativo dinâmico sobre HTTP (DASH).
- 39. Dispositivo, de acordo com a reivindicação 32, em que o dispositivo compreende pelo menos um de:um circuito integrado;um microprocessador; ou um dispositivo de comunicação sem fio.
- 40. Dispositivo para recuperação de dados de
mídia, o dispositivo compreendendo: meios para recuperação de um arquivo manifesto especificando dados para pelo menos uma representação de uma apresentação de mídia, em que o arquivo manifesto inclui dados que especificam um ou mais codecs para a pelo menos uma representação;meios para extrair, do arquivo manifesto, osPetição 870190095055, de 23/09/2019, pág. 83/9411/12 dados que especificam os um ou mais codecs, incluindo:meios para extrair um primeiro elemento representando um código tipo de entrada de amostra de uma faixa da pelo menos uma representação, em que o primeiro elemento representa que a faixa inclui dados de video armazenados usando um esquema restrito; e meios para extrair um segundo elemento representando um código tipo de esquema restrito para o esquema restrito da faixa; e meios para recuperação de dados de mídia da pelo menos uma representação com base no primeiro elemento e no segundo elemento. - 41. Meio de armazenamento legível por computador tendo nele armazenadas instruções que, quando executadas, levam o processador a:recuperar um arquivo manifesto especificando dados para pelo menos uma representação de uma apresentação de mídia, em que o arquivo manifesto inclui dados que especificam um ou mais codecs para a pelo menos uma representação;extrair, do arquivo manifesto, os dados que especificam os um ou mais codecs, incluindo instruções que levam o processador a:extrair um primeiro elemento representando um código tipo de entrada de amostra de uma faixa da pelo menos uma representação, em que o primeiro elemento representa que a faixa inclui dados de vídeo armazenados usando um esquema restrito; e extrair um segundo elemento representando um código tipo de esquema restrito para o esquema restritoPetição 870190095055, de 23/09/2019, pág. 84/9412/12 da faixa; e recuperar dados de mídia da pelo menos uma representação com base no primeiro elemento e no segundo elemento.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201762477350P | 2017-03-27 | 2017-03-27 | |
| US15/935,553 US10805650B2 (en) | 2017-03-27 | 2018-03-26 | Signaling important video information in network video streaming using mime type parameters |
| PCT/US2018/024530 WO2018183300A1 (en) | 2017-03-27 | 2018-03-27 | Signaling important video information in network video streaming using mime type parameters |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BR112019019836A2 true BR112019019836A2 (pt) | 2020-04-22 |
Family
ID=63583790
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BR112019019836A BR112019019836A2 (pt) | 2017-03-27 | 2018-03-27 | sinalização de informações importantes de vídeo em streaming de vídeo em rede usando parâmetros tipo mime |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US10805650B2 (pt) |
| EP (1) | EP3603096A1 (pt) |
| KR (1) | KR102614207B1 (pt) |
| CN (1) | CN110431850B (pt) |
| AU (1) | AU2018244288A1 (pt) |
| BR (1) | BR112019019836A2 (pt) |
| SG (1) | SG11201907574YA (pt) |
| TW (1) | TWI774744B (pt) |
| WO (1) | WO2018183300A1 (pt) |
Families Citing this family (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018182144A1 (ko) * | 2017-03-29 | 2018-10-04 | 엘지전자 주식회사 | 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치 |
| BR112019024597A2 (pt) * | 2017-05-30 | 2020-06-09 | Sony Corp | aparelho e método de processamento de imagem, programa para fazer com que um computador execute processamento, e, aparelho e método de geração de arquivo |
| US10630994B2 (en) * | 2017-06-28 | 2020-04-21 | Agora Lab, Inc. | Specific operation prediction in video compression |
| EP4322533A3 (en) | 2018-06-29 | 2024-03-06 | Beijing Bytedance Network Technology Co., Ltd. | Checking order of motion candidates in lut |
| CN110662043B (zh) | 2018-06-29 | 2021-12-21 | 北京字节跳动网络技术有限公司 | 一种用于处理视频数据的方法、装置和计算机可读介质 |
| CN110662052B (zh) | 2018-06-29 | 2022-07-08 | 北京字节跳动网络技术有限公司 | 更新查找表(lut)的条件 |
| TWI731360B (zh) | 2018-06-29 | 2021-06-21 | 大陸商北京字節跳動網絡技術有限公司 | 查找表的使用條件 |
| TWI728390B (zh) | 2018-06-29 | 2021-05-21 | 大陸商北京字節跳動網絡技術有限公司 | 查找表尺寸 |
| EP3791585A1 (en) | 2018-06-29 | 2021-03-17 | Beijing Bytedance Network Technology Co. Ltd. | Partial/full pruning when adding a hmvp candidate to merge/amvp |
| SG11202012293RA (en) | 2018-06-29 | 2021-01-28 | Beijing Bytedance Network Technology Co Ltd | Update of look up table: fifo, constrained fifo |
| WO2020008349A1 (en) | 2018-07-02 | 2020-01-09 | Beijing Bytedance Network Technology Co., Ltd. | Merge index coding |
| WO2020053800A1 (en) | 2018-09-12 | 2020-03-19 | Beijing Bytedance Network Technology Co., Ltd. | How many hmvp candidates to be checked |
| WO2020084476A1 (en) | 2018-10-22 | 2020-04-30 | Beijing Bytedance Network Technology Co., Ltd. | Sub-block based prediction |
| WO2020084475A1 (en) | 2018-10-22 | 2020-04-30 | Beijing Bytedance Network Technology Co., Ltd. | Utilization of refined motion vector |
| CN111436230A (zh) | 2018-11-12 | 2020-07-21 | 北京字节跳动网络技术有限公司 | 仿射预测的带宽控制方法 |
| CN113170171B (zh) | 2018-11-20 | 2024-04-12 | 北京字节跳动网络技术有限公司 | 组合帧间帧内预测模式的预测细化 |
| EP3861742A4 (en) | 2018-11-20 | 2022-04-13 | Beijing Bytedance Network Technology Co., Ltd. | DIFFERENCE CALCULATION BASED ON SPATIAL POSITION |
| JP7275286B2 (ja) | 2019-01-10 | 2023-05-17 | 北京字節跳動網絡技術有限公司 | Ｌｕｔ更新の起動 |
| WO2020143824A1 (en) | 2019-01-13 | 2020-07-16 | Beijing Bytedance Network Technology Co., Ltd. | Interaction between lut and shared merge list |
| WO2020147772A1 (en) | 2019-01-16 | 2020-07-23 | Beijing Bytedance Network Technology Co., Ltd. | Motion candidates derivation |
| JP2022521554A (ja) | 2019-03-06 | 2022-04-08 | 北京字節跳動網絡技術有限公司 | 変換された片予測候補の利用 |
| WO2020192611A1 (en) | 2019-03-22 | 2020-10-01 | Beijing Bytedance Network Technology Co., Ltd. | Interaction between merge list construction and other tools |
| EP3922014A4 (en) | 2019-04-02 | 2022-04-06 | Beijing Bytedance Network Technology Co., Ltd. | DECODER SIDE MOTION VECTOR BYPASS |
| US11388427B2 (en) * | 2020-01-09 | 2022-07-12 | Qualcomm Incorporated | Multiple decoder interface for streamed media data |
| 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 |
| CN115529491B (zh) * | 2022-01-10 | 2023-06-06 | 荣耀终端有限公司 | 一种音视频解码的方法、音视频解码的装置以及终端设备 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| NZ599303A (en) | 2009-10-20 | 2014-06-27 | Ericsson Telefon Ab L M | Provision of supplemental processing information |
| CN107911332B (zh) | 2009-11-04 | 2021-01-08 | 阿莫泰克有限公司 | 媒体内容流播的方法、系统和计算机可读介质 |
| US9621617B2 (en) * | 2012-02-28 | 2017-04-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and server for sending a data stream to a client and method and client for receiving a data stream from a server |
| EP3257216B1 (en) * | 2015-02-11 | 2021-01-27 | Expway | Method of handling packet losses in transmissions based on dash standard and flute protocol |
-
2018
- 2018-03-26 US US15/935,553 patent/US10805650B2/en active Active
- 2018-03-27 SG SG11201907574Y patent/SG11201907574YA/en unknown
- 2018-03-27 AU AU2018244288A patent/AU2018244288A1/en not_active Abandoned
- 2018-03-27 TW TW107110573A patent/TWI774744B/zh active
- 2018-03-27 CN CN201880019398.XA patent/CN110431850B/zh active Active
- 2018-03-27 EP EP18718281.1A patent/EP3603096A1/en active Pending
- 2018-03-27 KR KR1020197031753A patent/KR102614207B1/ko active IP Right Grant
- 2018-03-27 WO PCT/US2018/024530 patent/WO2018183300A1/en unknown
- 2018-03-27 BR BR112019019836A patent/BR112019019836A2/pt unknown
Also Published As
| Publication number | Publication date |
|---|---|
| CN110431850A (zh) | 2019-11-08 |
| US20180278971A1 (en) | 2018-09-27 |
| KR102614207B1 (ko) | 2023-12-14 |
| TW201841512A (zh) | 2018-11-16 |
| TWI774744B (zh) | 2022-08-21 |
| AU2023200083A1 (en) | 2023-02-09 |
| WO2018183300A1 (en) | 2018-10-04 |
| US10805650B2 (en) | 2020-10-13 |
| SG11201907574YA (en) | 2019-10-30 |
| EP3603096A1 (en) | 2020-02-05 |
| CN110431850B (zh) | 2022-02-01 |
| KR20190132464A (ko) | 2019-11-27 |
| AU2018244288A1 (en) | 2019-09-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BR112019019836A2 (pt) | sinalização de informações importantes de vídeo em streaming de vídeo em rede usando parâmetros tipo mime | |
| KR102342274B1 (ko) | 이미지에서 가장 관심있는 영역의 진보된 시그널링 | |
| ES2892329T3 (es) | Señalización de datos para el soporte de prebúsqueda para datos multimedia de transmisión continua | |
| BR112020000328A2 (pt) | empacotamento região a região, cobertura de conteúdo e sinalização de empacotamento de quadro para conteúdo de mídia | |
| TW201924323A (zh) | 用於浸入式媒體資料之內容來源描述 | |
| JP2019521584A (ja) | Ｈｔｔｐを介した動的適応型ストリーミングにおけるバーチャルリアリティビデオのシグナリング | |
| US11665219B2 (en) | Processing media data using a generic descriptor for file format boxes | |
| JP7035088B2 (ja) | 魚眼ビデオデータのための高レベルシグナリング | |
| TWI711303B (zh) | 用於魚眼虛擬實境視訊之增強的高階發信號 | |
| BR112020000110A2 (pt) | sinalização de alto nível aprimorada para vídeo de realidade virtual de fisheye em dash | |
| CN111034203A (zh) | 处理具有动态逐区封装的全向媒体 | |
| CN110832878B (zh) | 增强区域取向包封及视区独立高效视频译码媒体配置文件 | |
| CN110870323B (zh) | 使用全向媒体格式处理媒体数据 | |
| AU2023200083B2 (en) | Signaling important video information in network video streaming using mime type parameters |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B350 | Update of information on the portal [chapter 15.35 patent gazette] |