BR112017027511B1 - Distribuição de middleware de métricas de qoe de cliente dash - Google Patents

Abstract

DISTRIBUIÇÃO DE MIDDLEWARE DE MÉTRICAS DE QOE DE CLIENTE DASH. Um dispositivo ilustrativo para a geração de reportes de medição de qualidade inclui um ou mais processadores com base em hardware implementados utilizando-se um conjunto de circuitos digital, os processadores sendo configurados para executar uma unidade de middleware e um aplicativo alvo para os dados de mídia. A unidade de middleware é configurada para receber dados de mídia através da difusão ou multidifusão a partir de um dispositivo servidor, gerar reportes de recepção cobrindo a recepção dos dados de mídia de acordo com as diretivas de reporte recebidas, distribuir pelo menos parte dos dados de mídia para um aplicativo alvo do dispositivo de cliente, receber reportes de qualidade de experiência (QoE) do aplicativo alvo, e fornecer conteúdo dos reportes de QoE para um servidor de reporte de recepção.

Description

[01] Esse pedido reivindica os benefícios do pedido provisório U.S. No. 62/182.267 depositado em 19 de junho de 2015, a totalidade de seu conteúdo sendo incorporada aqui por referência.

Campo Técnico

[02] Essa descrição se refere ao transporte de dados de mídia.

Fundamentos

[03] Capacidades de vídeo digital podem ser incorporadas a uma ampla faixa de dispositivos, incluindo televisores digirais, sistemas de difusão direta digital, sistemas de difusão sem fio, assistentes digitais pessoais (PDAs), computadores laptop ou desktop, câmeras digitais, dispositivos de gravação digital, aparelhos de mídia digital, dispositivos de jogos de vídeo, consoles de jogos de vídeo, telefones de rádio celular ou via satélite, dispositivos de teleconferência de vídeo, e similares. Adicionalmente, os dispositivos servidores (tal como servidores de rede, dispositivos de redes de distribuição de conteúdo (CDNs) e similares) podem transmitir dados de mídia para dispositivos de clientes (tal como computadores pessoais, caixas de decodificação, dispositivos móveis, tal como laptops, telefones celulares e similares), por exemplo, através de protocolos de rede de transmissão ou por demanda. Os dispositivos de vídeo digitais implementam as técnicas de compressão de vídeo, tal como as descritas nos padrões definidos por MPEG-2, MPEG-4, ITU-T H.263 ou ITU-T H.264/MPEG-4, Parte 10, Codificação de Vídeo Avançada (AVC), ITU-T H.265 (também conhecido como Codificação de Vídeo de Alta Eficiência (HEVC)), e extensões de tais padrões, para transmitir e receber informação de vídeo digital de forma mais eficiente.

[04] Depois da codificação dos dados de vídeo, os dados de podem ser empacotados para transmissão ou armazenamento. Os dados de vídeo podem ser montados em um arquivo de vídeo em conformidade com qualquer um dentre uma variedade de padrões, tal como o formato de arquivo de mídia de base da Organização Internacional para Padronização (ISO), e extensões do mesmo, tal como AVC.

[05] Os dados, tal como dados de mídia incluindo vídeo, áudio e dados de texto temporizados, podem ser distribuídos em uma variedade de métodos de transporte. Um desses métodos é o serviço de difusão/multidifusão de multimídia (MBMS) nas redes do Projeto de Parceria de 3a. Geração (3GPP). MBMS, por exemplo, permite a distribuição de serviços de interesse para um grande número de assinantes utilizando um único canal de distribuição.

[06] O reporte de Qualidade de Experiência (QoE) pelos clientes de vídeo é crucial para o monitoramento do desempenho de distribuição em um sistema e para a calibragem da qualidade de visualização do usuário final. MBMS, por exemplo, fornece métodos de medição da qualidade de transporte e QoE de usuário através de sua estrutura de reporte de recepção. Os métodos de distribuição de vídeo também podem incluir seus próprios reportes de medição de qualidade criando 2 pontos de reporte diferentes em um dispositivo final. A agregação de dois tipos de reporte (os tipos MBMS e cliente de vídeo) é válida para se garantir que os reportes consolidados, que cobrem múltiplos aspectos do desempenho de distribuição de conteúdo, estejam facilmente disponíveis para os provedores de serviço.

Sumário

[07] Em geral, essa descrição descreve técnicas relacionadas com a distribuição de Transmissão Adaptativa Dinâmica através de métricas de qualidade de experiência (QoE) de clientes HTTP (DASH) para um servidor de reporte por uma unidade de middleware. Isso é, um dispositivo de cliente pode incluir um cliente DASH (por exemplo, uma unidade dentro do dispositivo de cliente, tal como uma unidade de hardware dedicado ou um módulo de software, tal como uma extensão do navegador de rede) que implementa DASH para recuperação de dados de mídia, e uma unidade de middleware que recebe dados de mídia utilizando um serviço de difusão ou multidifusão, tal como os Serviços de Difusão/Multidifusão de Multimídia (MBMS) ou MBMS melhorado (eMBMS). A unidade de middleware também age como um servidor proxy com relação ao cliente DASH, visto que a unidade de middleware armazena temporariamente os dados de mídia recebidos e fornece os dados de mídia para o cliente DASH em resposta às solicitações geradas pelo dispositivo do cliente. Ademais, a unidade de middleware pode receber os reportes de métricas de QoE DASH do dispositivo de cliente, e distribuir esses reportes de métricas de QoE DASH para um servidor de reporte em nome do cliente DASH.

[08] Em um exemplo, um método de geração de reportes de medição de qualidade é realizado por uma unidade de middleware de um dispositivo de cliente e inclui o recebimento de dados de mídia através da difusão ou multidifusão a partir de um dispositivo servidor, gerando reportes de recepção que cobrem a recepção dos dados de mídia de acordo com as diretivas do reporte recebido, distribuindo pelo menos parte dos dados de mídia para um aplicativo alvo do dispositivo de cliente, recebendo reportes sobre a qualidade de experiência (QoE) do aplicativo alvo, e fornecendo conteúdo dos reportes de QoE para um servidor de reporte de recepção. Novamente, nesse exemplo, os reportes de recepção incluem o conteúdo dos reportes de QoE, mas em outros exemplos, esses reportes podem ser distribuídos separadamente e/ou para servidores de reporte separados.

[09] Em outro exemplo, um dispositivo para a geração de reportes de medição de qualidade inclui um ou mais processadores com base em hardware implementados utilizando-se um conjunto de circuitos digital, os processadores sendo configurados para executar uma unidade de middleware e um aplicativo alvo para dados de mídia. A unidade de middleware é configurada para receber os dados de mídia através de difusão ou multidifusão de um dispositivo servidor, gerar reportes de recepção cobrindo a recepção de dados de mídia de acordo com as diretivas do reporte recebido, distribuir pelo menos parte dos dados de mídia para um aplicativo alvo do dispositivo de cliente, receber reportes de qualidade de experiência (QoE) do aplicativo alvo, e fornecer conteúdo dos reportes de QoE para um servidor de reporte de recepção.

[010] Em outro exemplo, um dispositivo para a geração de reportes de medição e qualidade inclui meios para receber dados de mídia através de difusão ou multidifusão de um dispositivo servidor, meios para gerar reportes de recepção que cobrem a recepção dos dados de mídia de acordo com as diretivas do reporte recebido, meios para distribuir pelo menos parte dos dados de mídia para um aplicativo alvo do dispositivo, meios para receber reportes de qualidade de experiência (QoE) do aplicativo alvo, e meios para fornecer conteúdo dos reportes de QoE para um servidor de reporte de recepção.

[011] Em outro exemplo, um meio de armazenamento legível por computador possui armazenadas no mesmo instruções que, quando executadas, fazem com que um processador de um dispositivo de cliente receba dados de mídia através da difusão ou multidifusão de um dispositivo servidor, gere reportes de recepção cobrindo a recepção dos dados de mídia de acordo com as diretivas do reporte recebido, distribua pelo menos parte dos dados de mídia para um aplicativo alvo do dispositivo de cliente, receba reportes de qualidade de experiência (QoE) do aplicativo alvo, e forneça conteúdo dos reportes de QoE para um servidor de reporte de recepção.

[012] Os detalhes de um ou mais exemplos são apresentados nos desenhos em anexo e na descrição abaixo. Outras características, objetivos e vantagens serão aparentes a partir da descrição e dos desenhos e a partir das reivindicações.

Breve Descrição dos Desenhos

[013] A figura 1 é um diagrama conceitual ilustrando um sistema que utiliza as técnicas de reporte tradicionais.

[014] A figura 2 é um diagrama conceitual ilustrando um sistema ilustrativo de acordo com as técnicas dessa descrição.

[015] A figura 3 é um diagrama conceitual ilustrando outro sistema ilustrativo de acordo com as técnicas dessa descrição.

[016] A figura 4 é um diagrama em bloco ilustrando um sistema ilustrativo que implementa as técnicas para a transmissão de dados de mídia através de uma rede.

[017] A figura 5 é um diagrama em bloco de um conjunto ilustrativo de componentes da unidade de recuperação da figura 4 em maiores detalhes.

[018] A figura 6 é um diagrama conceitual ilustrando elementos do conteúdo de multimídia ilustrativo.

[019] A figura 7 é um diagrama em bloco ilustrando os elementos de um arquivo de vídeo ilustrativo.

[020] A figura 8 é um diagrama conceitual ilustrando dados ilustrativos que podem ser incluídos em um arquivo de manifesto, tal como uma descrição de apresentação de mídia (MPD) de DASH, de acordo com as técnicas dessa descrição.

[021] A figura 9 é um diagrama conceitual ilustrando uma modificação ilustrativa de uma descrição de procedimento de distribuição associada (ADPD) de acordo com as técnicas dessa descrição.

[022] A figura 10 é um diagrama conceitual ilustrando um esquema alternativo para uma ADPD de acordo com as técnicas dessa descrição.

[023] A figura 11A é um diagrama conceitual ilustrando um exemplo das técnicas dessa descrição.

[024] A figura 11B é um diagrama conceitual ilustrando um exemplo de comportamento com recepção de unidifusão/difusão paralela.

[025] A figura 12 é um diagrama conceitual ilustrando um exemplo de comportamento com múltiplos clientes DASH.

[026] A figura 13 é um fluxograma ilustrando um método ilustrativo de acordo com as técnicas dessa descrição.

[027] A figura 14 é um fluxograma ilustrando outro método ilustrativo de acordo com as técnicas dessa descrição.

[028] A figura 15 é um diagrama em bloco ilustrando os exemplos de um dispositivo servidor e um dispositivo de cliente configurados de acordo com as técnicas dessa descrição.

Descrição Detalhada

[029] Em geral, essa descrição descreve as técnicas de reporte de métricas de qualidade de experiência (QoE) para um ou mais servidores. Em particular, essas técnicas podem ser aplicadas onde um dispositivo de cliente (também referido como um equipamento de usuário (UE)) inclui uma unidade de middleware que permite que um aplicativo de transmissão acesse a difusão de conteúdo através de uma rede LTE. O middleware também age como o servidor http para o conteúdo de difusão servidor para o aplicativo de transmissão (o aplicativo de transmissão pode ser uma transmissão adaptativa dinâmica através do cliente HTTP (DASH)) executado pelo dispositivo de cliente. Ao passo que, de forma convencional, o cliente DASH reportaria as métricas de QoE para um servidor, as técnicas dessa descrição permitem que a unidade de middleware instrua o cliente DASH a reportar as métricas de QoE para o middleware, alternativamente, ou adicionalmente ao reporte das métricas de QoE DASH para o servidor. O middleware incluirá, então, o reporte de medição de QoE DASH no, ou anexará o mesmo a um, reporte de recepção MBMS. As técnicas dessa descrição são geralmente direcionadas à unidade de middleware recebendo as métricas de QoE do aplicativo de transmissão e fornecendo as métricas de QoE para o servidor de reporte de recepção basicamente, e, opcionalmente, para o servidor de QoE DASH.

[030] A figura 1 é um diagrama conceitual ilustrando um sistema 100 que utiliza as técnicas de reporte convencionais. Nesse exemplo, o sistema 100 inclui o equipamento de usuário (UE) 106, incluindo um cliente de dispositivo de serviço de multidifusão (MSDC) 112, que é um exemplo de uma unidade de middleware, e um cliente DASH 108. O UE 106 representa um exemplo de dispositivo de cliente, tal como um computador pessoal, um telefone celular, um laptop, um tablet, uma caixa de decodificação, ou similar. MSDC 112 também pode ser referido como uma unidade de middleware de Serviço de Difusão e Multidifusão de Multimídia (MBMS), uma unidade de middleware de Serviço de Difusão e Multidifusão de Multimídia melhorado (eMBMS), ou cliente DASH 108.

[031] Nesse exemplo, um centro de serviço de difusão e multidifusão e servidor de provisionamento (BMSC) 104 distribui anúncios de serviço 118 para o MSDC 112 do UE 106. Os anúncios de serviço 118 incluem, por exemplo, um arquivo manifesto (tal como uma descrição de apresentação de mídia (MPD) 122), um protocolo de descrição de sessão (SDP) e/ou uma descrição de procedimento de distribuição associada (ADPD). A unidade de reporte de recepção 114 do MSDC 112 coleta estatísticas de recepção de acordo com as métricas especificadas no fragmento SDP em um anúncio de serviço 118 e as diretivas de reporte de recepção no fragmento ADPD no anúncio de serviço 118.

[032] A MPD DASH 122 também pode especificar as métricas para o cliente DASH 108 para serem coletadas. Dessa forma, o cliente DASH 108 inclui a unidade de QoE DASH 118, que coleta as métricas especificadas (também descritas como medições) 116 e carrega as métricas de QoE 116 para o servidor de coleta de métrica de qualidade DASH 102. Dessa forma, nesse exemplo, existem dois pontos de coleta diferentes, o primeiro (servidor de coleta de métrica de qualidade DASH 102) para as métricas de QoE e o segundo (servidor de provisionamento e BMSC 104) para as métricas de reporte de recepção MBMS 120.

[033] A figura 2 é um diagrama conceitual ilustrando um sistema ilustrativo 100' de acordo com as técnicas dessa descrição. De acordo com as técnicas dessa descrição, o cliente DASH 108' do UE 106', no exemplo da figura 2, carrega as métricas de QoE DASH 116' para MSDC 112' do UE 106'. Em particular, o servidor de provisionamento e BMSC 104 envia o anúncio de serviço 118', incluindo MPD e segmentos 122' nesse exemplo. MSDC 112' envia MPD e segmentos 122' para o cliente DASH 108. MPD inclui diretivas de reporte DASH. De acordo com as técnicas dessa descrição, QoE DASH 110' envia métricas de QoE DASH 116' para MSDC 112', de acordo com MPD. Dessa forma, MSDC 112' pode coletar o reporte de medições de QoE DASH 116', e a unidade de reporte de recepção 114' pode incluir o reporte de medições de QoE DASH em um reporte de recepção correspondente 120' (que pode ser coletado e reportado de acordo com o padrão MBMS 3GPP).

[034] Por exemplo, MSDC 112' pode modificar uma seção MPD nas métricas a serem carregadas, para permitir a postagem de medições de QoE DASH para um servidor HTTP hospedado pelo MSDC 112'. A modificação de MPD já pode ser feita pelo middleware (por exemplo, MSDC 112') para apontar URLs de segmento na MPD para um servidor HTTP local hospedado por MSDC 112'. MSDC 112' também pode ser configurado para aceitar os comandos HTTP POST relacionados com a coleta de QoE DASH, por exemplo, do cliente DASH 108'. Adicionalmente, MSDC 112' pode embutir arquivos de registro de QoE DASH nos reportes de recepção correspondentes 120'. Nesse exemplo, o UE 106' não precisa reportar os reportes de QoE DASH para o servidor de coleta de métrica de qualidade DASH 102'. Em vez disso, o UE 106' pode simplesmente submeter os reportes de métricas de QoE DASH 116' juntamente com os reportes de recepção MBMS para o servidor de provisionamento e BMSC 104'. Subsequentemente, BMSC 104' pode submeter os reportes de QoE DASH para o servidor de coleta de métrica de qualidade DASH 102'.

[035] A figura 3 é um diagrama conceitual ilustrando outro sistema ilustrativo 100" de acordo com as técnicas dessa descrição. Em geral, esse exemplo é similar ao exemplo da figura 2, exceto que no exemplo da figura 3, o UE 106" reporta as medições de QoE 116" para o servidor de coleta de métrica de qualidade DASH 102" em adição ao servidor de provisionamento e BMSC 104" com os reportes de recepção MBMS 120". Isso é, nesse exemplo, o servidor de provisionamento e BMSC 104 envia o anúncio de serviço 118" para o UE 106, e o MSDC 112" do UE 106 extrai e envia MPD e segmentos 122" para o cliente DASH 108. A unidade de QoE DASH 110" reporta as métricas de QoE DASH 116" para o MSDC 112". Adicionalmente, qualquer um ou ambos a QoE DASH 110" e/ou MSDC 112" enviam um reporte de QoE DASH duplicado, proxy ou adicional para o servidor de coleta de métrica de qualidade DASH 102, como explicado em maiores detalhes abaixo.

[036] As métricas de QoE podem variar com base no servidor ao qual as métricas são reportadas. Adicionalmente, as métricas reportadas podem depender, nesse exemplo, do padrão DASH utilizado (por exemplo, 3GP- DASH X MPEG-DASH). Em 3GP-DASH, por exemplo, o cliente DASH 108 pode reportar o rendimento médio, o retardo de transmissão inicial, e informação MPD, em adição a uma lista de transações de Solicitação/Reposta HTTP, uma lista de eventos de comutação de representação, um nível de armazenamento e/ou uma lista de reprodução. Em MPEG-DASH, por outro lado, as métricas reportadas podem incluir uma lista de conexões TCP, em adição a uma lista de transações de solicitação/reposta HTTP, uma lista de eventos de comutação de representação, um nível de armazenamento e/ou uma lista de reprodução.

[037] A seção 10.6 de 3GP-DASH 26.247, versão d00, especifica que o protocolo de reporte de qualidade inclui o formato de reporte com base em XML definido na Seção 10.6.2 de 3GP-DASH e o protocolo de reporte definido na Seção 10.6.3 de 3GP-DASH. Adicionalmente, 3GP-DASH especifica o tipo MIME de um reporte de QoE de formato XML como "application/3gpdash-qoe-report+xml", como definido no Anexo J apresentado aqui.

[038] Considera-se, nesse exemplo, que um provedor de conteúdo e/ou um operador desejem que um reporte seja carregado para o servidor de coleta de métrica de qualidade DASH 102". Dessa forma, nesse exemplo, o cliente DASH 108" (em particular, QoE DASH 110") pode postar um reporte diretamente para MSDC 112" (postar para um local localhost) e MSDC 112" pode duplicar o reporte para o servidor de coleta de métrica de qualidade DASH 102" (seta B na figura 3, com alternativa duplicada, referido como "reporte de QoE DASH proxied/duplicado 116"B). Alternativamente, em vez de reportar a QoE DASH 110" as métricas de QoE DASH para MSDC 112" diretamente, o MSDC 112" pode interceptar o reporte de medição em seu percurso para o servidor de coleta de métrica de qualidade DASH 102" (seta B na figura 3, com alternativa proxied, referido como "reporte de QoE DASH proxied/duplicado 116"B).

[039] Adicionalmente ou alternativamente, o cliente DASH 108" pode emitir múltiplos reportes: um para MSDC 112" e outro para o servidor de coleta de métrica de qualidade DASH 102" (seta A na figura 3, referido como "reporte de QoE DASH duplicado/outro 116"A). Os reportes podem ser para métricas diferentes ou para as mesmas métricas com base nas mesmas ou em outras diretivas de coleta e carregamento.

[040] No exemplo de transmissão de dados 3GPP utilizando-se a transmissão HTTP, pode haver múltiplas representações para dados de vídeo e/ou áudio do conteúdo de multimídia. Como explicado abaixo, diferentes representações podem corresponder a diferentes características de codificação (por exemplo, diferentes perfis ou níveis de um padrão de codificação de vídeo), diferentes padrões de codificação ou extensões de padrões de codificação (tal como extensões de múltiplas visualizações e/ou extensões escalonáveis), ou taxas de dados diferentes. O manifesto de tais representações pode ser definido em uma estrutura de dados de Descrição de Apresentação de Mídia (MPD). Uma apresentação de mídia particular pode corresponder a uma coleção estruturada de dados que é acessível a um dispositivo de cliente de transmissão HTTP. O dispositivo de cliente de transmissão HTTP pode solicitar e descarregar informação de dados de mídia para apresentar um serviço de transmissão para um usuário do dispositivo de cliente. Uma apresentação de mídia pode ser descrita na estrutura de dados MPD, que pode incluir atualizações de MPD.

[041] Uma apresentação de mídia pode conter uma sequência de um ou mais períodos. Cada período pode conter uma ou mais representações para o mesmo conteúdo de mídia. Uma representação pode ser uma dentre várias das versões codificadas alternativas de dados de áudio ou vídeo. 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 bit, linguagem e/ou codec para dados de áudio. O termo representação pode ser utilizado para se referir a uma seção de dados de áudio ou vídeo codificados correspondendo a um período particular do conteúdo de multimídia e codificada de uma forma particular.

[042] Representações de um período particular podem ser designadas 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 uma para a outra, visto que um dispositivo de cliente pode comutar de forma dinâmica e contínua entre essas representações, por exemplo, para realizar a adaptação de largura de banda. Por exemplo, cada representação dos dados de vídeo para um período particular pode ser designada para o mesmo conjunto de adaptação, de modo que qualquer uma das representações possa ser selecionada para decodificação para apresentar os dados de mídia, tal como dados de vídeo ou dados de áudio, do conteúdo de multimídia para o período correspondente. O conteúdo de mídia dentro de um período pode ser apresentado 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 temporização para cada representação de um período podem ser expressos com relação ao momento inicial do período.

[043] 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 ter inicialização automática. Quando presente, o segmento de inicialização pode conter a informação de inicialização para acessar a representação. Em geral, o segmento de inicialização não contém dados de mídia. Um segmento pode ser referido de forma singular por um identificador, tal como o localizador de recurso uniforme (URL), nome de recurso uniforme (URN), ou identificador de recurso uniforme (URI). A MPD pode fornecer identificadores para cada segmento. Em alguns exemplos, MPD também pode fornecer faixas de bytes na forma de um atributo de faixa, que pode corresponder aos dados para um segmento dentro de um arquivo acessível pelo URL, URN ou URI

[044] Diferentes representações podem ser selecionadas para a recuperação substancialmente simultânea para diferentes tipos de dados de mídia. Por exemplo, um dispositivo de cliente pode selecionar uma representação de áudio, uma representação de vídeo, e uma representação de texto temporiza de onde se recupera os segmentos. Em alguns exemplos, o dispositivo de cliente pode selecionar conjuntos de adaptação particulares para a realização de adaptação de largura de banda. Isso é, o dispositivo de cliente pode selecionar um conjunto de adaptação incluindo representações de vídeo, um conjunto de adaptação incluindo representações de áudio e/ou um conjunto de adaptação incluindo texto temporizado. Alternativamente, o dispositivo de cliente pode selecionar conjuntos de adaptação para determinados tipos de mídia (por exemplo, vídeo) e selecionar diretamente as representações para outros tipos de mídia (por exemplo, áudio e/ou texto temporizado).

[045] A figura 4 é um diagrama em bloco ilustrando um sistema ilustrativo 130 que implementa as técnicas para transmissão de dados de mídia através de uma rede. Nesse exemplo, o sistema 130 inclui o dispositivo de preparação de conteúdo 140, o dispositivo servidor 160 e o dispositivo de cliente 180. O dispositivo de cliente 180 e o dispositivo de servidor 160 são acoplados de forma comunicativa pela rede 174, que pode compreender a Internet. Em alguns exemplos, o dispositivo de preparação de conteúdo 140 e o dispositivo servidor 160 também podem ser acoplados pela rede 174 ou outra rede, ou podem ser acoplados de forma comunicativa diretamente. Em alguns exemplos, o dispositivo de preparação de conteúdo 140 e o dispositivo servidor 160 podem compreender o mesmo dispositivo.

[046] O dispositivo de preparação de conteúdo 140, no exemplo da figura 4, compreende fonte de áudio 142 e fonte de vídeo 144. A fonte de áudio 142 pode compreender, por exemplo, um microfone que produz sinais elétricos representativos dos dados de áudio capturados a serem codificados pelo codificador de áudio 146. Alternativamente, a fonte de áudio 142 pode compreender um meio de armazenamento armazenando os dados de áudio gravados previamente, um gerador de dados de áudio tal como um sintetizador computadorizado, ou qualquer outra fonte de dados de áudio. A fonte de vídeo 144 pode compreender uma câmera de vídeo que produz dados de vídeo a serem codificados pelo codificador de vídeo 148, um meio de armazenamento codificado com dados de vídeo gravados previamente, uma unidade de geração de dados de vídeo tal como uma fonte de gráficos de computador, ou qualquer outra fonte de dados de vídeo. O dispositivo de preparação de conteúdo 140 não está necessariamente acoplado de forma comunicativa ao dispositivo servidor 160 em todos os exemplos, mas pode armazenar conteúdo de multimídia em um meio separado que é lido pelo dispositivo servidor 160.

[047] Os dados de áudio e vídeo brutos podem compreender dados analógicos ou digitais. Os dados analógicos podem ser digitalizados antes de serem codificados pelo codificador de áudio 146 e/ou codificador de vídeo 148. A fonte de áudio 142 pode obter dados de áudio de um participante interlocutor enquanto o participante interlocutor está falando, e a fonte de vídeo 144 pode obter, simultaneamente, dados de vídeo do participante interlocutor. Em outros exemplos, a fonte de áudio 142 pode compreender um meio de armazenamento legível por computador compreendendo dados de áudio armazenados, e a fonte de vídeo 144 pode compreender um meio de armazenamento legível por computador compreendendo dados de vídeo armazenados. Dessa forma, as técnicas descritas nessa descrição podem ser aplicadas a dados de áudio e vídeo ao vivo, transmitidos em tempo real ou a dados de áudio e vídeo arquivados, pré-gravados.

[048] 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 142 simultaneamente com os dados de vídeo capturados (ou gerados) pela fonte de vídeo 144 que está contida dentro dos quadros de vídeo. Por exemplo, enquanto um participante interlocutor geralmente produz dados de áudio por meio da fala, a fonte de áudio 142 captura os dados de áudio, e a fonte de vídeo 144 captura os dados de vídeo do participante interlocutor ao mesmo tempo, isso é, enquanto a fonte de áudio 142 está capturando os dados de áudio. Dessa forma, um quadro de áudio pode corresponder temporalmente a um ou mais quadros de vídeo em particular. De acordo, um quadro de áudio correspondendo a um quadro de vídeo corresponde geralmente a uma situação na qual os dados de áudio e os dados de vídeo foram capturados ao mesmo tempo e para a qual um quadro de áudio e um quadro de vídeo compreendem, respectivamente, os dados de áudio e os dados de vídeo que foram capturados ao mesmo tempo.

[049] Em alguns exemplos, o codificador de áudio 146 pode codificar um carimbo de tempo em cada quadro de áudio codificado que representa um horário no qual os dados de áudio para o quadro de áudio codificado foram gravados, e, de forma similar, o codificador de vídeo 148 pode codificar um carimbo de tempo em cada quadro de vídeo codificado que representa um horário no qual os dados de vídeo para o quadro de vídeo codificado foram gravados. Em tais exemplos, um quadro de áudio correspondendo a um quadro de vídeo podem compreender um quadro de áudio compreendendo um carimbo de tempo e um quadro de vídeo compreendendo o mesmo carimbo de tempo. O dispositivo de preparação de conteúdo 140 pode incluir um relógio interno a partir do qual o codificador de áudio 146 e/ou o codificador de vídeo 148 pode gerar os carimbos de tempo, ou a fonte de áudio 142 e a fonte de vídeo 144 pode utilizar para associar os dados de áudio e vídeo, respectivamente, com um carimbo de tempo.

[050] Em alguns exemplos, a fonte de áudio 142 pode enviar os dados para o codificador de áudio 146 correspondendo a um horário no qual os dados de áudio foram gravados, e a fonte de vídeo 144 pode enviar dados para o codificador de vídeo 148 correspondendo a um horário no qual os dados de vídeo foram gravados. Em alguns exemplos, o codificador de áudio 146 pode codificar um identificador de sequência nos dados de áudio codificados para indicar uma ordenação temporal relativa dos dados de áudio codificados, mas sem indicar, necessariamente, um horário absoluto no qual os dados de áudio foram gravados, e de forma similar, o codificador de vídeo 148 também pode utilizar os identificadores de sequência para indicar uma ordenação temporal relativa dos dados de vídeo codificados. De forma similar, em alguns exemplos, um identificador de sequência pode ser mapeado ou de outra forma correlacionado com um carimbo de tempo.

[051] O codificador de áudio 146 geralmente produz uma sequência de dados de áudio codificados, enquanto que o codificador de vídeo 148 produz uma sequência de dados de vídeo codificados. Cada sequência individual de dados (sejam eles de áudio ou vídeo) pode ser referida como uma sequência elementar. Uma sequência elementar é um componente singular, codificado digitalmente (possivelmente comprimido) de uma representação. Por exemplo, a parte de vídeo ou áudio codificada da representação pode ser uma sequência elementar. Uma sequência elementar pode ser convertida em uma sequência elementar empacotada (PES) antes de ser encapsulada dentro de um arquivo de vídeo. Dentro da mesma representação, um ID de sequência pode ser utilizado para distinguir os pacotes PES pertencentes a uma sequência elementar, de outros. A unidade básica de dados de uma sequência elementar é um pacote de sequências elementares empacotadas (PES). De forma similar, dados de áudio correspondem a uma ou mais sequências elementares respectivas.

[052] Muitos padrões de codificação de vídeo, tal como ITU-T H.264/AVC e o padrão de Codificação de Vídeo de Alta Eficiência (HEVC) futuro, definem a sintaxe, semântica e processo de decodificação para sequências de bit livres de erro, qualquer uma das quais se conforma a um perfil ou nível determinado. Os padrões de codificação de vídeo, tipicamente, não especificam o codificador, mas o codificador tem a tarefa de garantir que os fluxos de bits gerados estejam em conformidade com o padrão para um decodificador. No contexto de padrões de codificação de vídeo, um "perfil" corresponde a um subconjunto de algoritmos, características ou ferramentas e restrições que se aplicam aos mesmos. Como 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, tal como, por exemplo, a memória e computação do decodificador, que estão relacionadas com a resolução das imagens, taxa de bit e taxa de processamento de bloco. Um perfil pode ser sinalizado com um valor profile_idc (indicador de perfil), enquanto um nível pode ser sinalizado com um valor de level_idc (indicador de nível).

[053] O padrão H.264, por exemplo, reconhece que, dentro dos limites impostos pela sintaxe de um determinado perfil, ainda é possível se exigir uma grande variação no desempenho dos codificadores e decodificadores dependendo dos valores retirados pelos elementos de sintaxe no fluxo de bits tal como o tamanho especificado das imagens decodificadas. O padrão H.264 reconhece adicionalmente que, em muitas aplicações, não é prático nem econômico se implementar um decodificador capaz de lidar com todas as utilizações hipotéticas da sintaxe dentro de um perfil particular. De acordo, 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 limites simples sobre os valores. Alternativamente, essas restrições podem assumir a forma de restrições às combinações aritméticas de valores (por exemplo, largura de imagem multiplicada pela altura de imagem multiplicada pelo número de imagens decodificadas por segundo). O padrão H.264 fornece adicionalmente que as implementações individuais podem suportar um nível diferente para cada perfil suportado.

[054] Um decodificador em conformidade com um perfil normalmente suporta das as características definidas no perfil. Por exemplo, como uma característica 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 em conformidade com um nível deve poder decodificar qualquer fluxo de bits que não exija recursos além das limitações definidas no nível. As definições dos perfis e níveis podem ser úteis para fins de capacidade de interpretação. Por exemplo, durante a transmissão de vídeo, um par de definições de perfil e nível pode ser negociado e acordado para toda uma sessão de transmissão. Mais especificamente, no exemplo de H.264/AVC, um nível pode definir as limitações no número de macro blocos que precisam ser processados, tamanho de armazenamento de imagem decodificada (DPB), tamanho de armazenamento de imagem codificada (CPB), faixa de vetor de movimento vertical, número máximo de vetores de movimento por dois MBs consecutivos, e se um bloco B pode possuir partições de sub-macro bloco inferiores a 8 x 8 pixels. Dessa forma, um decodificador pode determinar se o decodificador é capaz de decodificar adequadamente o fluxo de bits.

[055] No exemplo da figura 4, a unidade de encapsulamento 150 do dispositivo de preparação de conteúdo 140 recebe sequências elementares compreendendo dados de vídeo codificados do codificador de vídeo 148 e sequências elementares compreendendo dados de áudio codificados do codificador de áudio 146. Em alguns exemplos, o codificador de vídeo 148 e o codificador de áudio 146 podem, cada um, incluir empacotadores para a formação de pacotes PES a partir dos dados codificados. Em outros exemplos, o codificador de vídeo 148 e o codificador de áudio 146 podem, cada um, interfacear com os respectivos empacotadores para a formação de pacotes PES a partir de dados codificados. Em outros exemplos ainda, a unidade de encapsulamento 150 pode incluir empacotadores para a formação de pacotes PES a partir de dados de áudio e vídeo codificados.

[056] O codificador de vídeo 148 pode codificar dados de vídeo de conteúdo de multimídia de uma variedade de formas, para produzir as diferentes representações do conteúdo de multimídia em várias taxas de bits e com várias características, tal como resoluções de pixel, taxas de quadro, conformidade a vários padrões de codificação, conformidade a vários perfis e/ou níveis de perfis para vários padrões de codificação, representações possuindo uma ou múltiplas visualizações (por exemplo, para reprodução bidimensional ou tridimensional) ou outras características similares. Uma representação, como utilizada nessa descrição, pode compreender um dentre dados de áudio, dados de vídeo, dados de texto (por exemplo, para legendas), ou outros dados similares. A representação pode incluir uma sequência elementar, tal como uma sequência elementar de áudio ou uma sequência elementar de vídeo. Cada pacote PES pode incluir um stream_id que identifica a sequência elementar à qual o pacote PES pertence. A unidade de encapsulamento 150 é responsável pela montagem das sequências elementares em arquivos de vídeo (por exemplo, segmentos) de várias representações.

[057] A unidade de encapsulamento 150 recebe pacotes PES para sequências elementares de uma representação a partir do codificador de áudio 146 e codificador de vídeo 148 e forma as unidades de camada de abstração de rede (NAL) correspondentes a partir dos pacotes PES. No exemplo de H.264/AVC (Codificação de Vídeo Avançada), os segmentos de vídeo codificados são organizados em unidades NAL, que fornecem uma representação de vídeo "favorável à rede" endereçando aplicativos tal como vídeo telefonia, armazenamento, difusão ou transmissão. Unidades NAL podem ser categorizadas em unidades NAL de Camada de Codificação de Vídeo (VCL) e unidades NAL não VCL. As unidades VCL podem conter o mecanismo de compressão de núcleo e podem incluir dados de nível de bloco, macro bloco e/ou fatia. Outras unidades NAL podem ser unidades NAL não VCL. Em alguns exemplos, uma imagem codificada em um momento, normalmente representada como uma imagem codificada primária, pode ser contida em uma unidade de acesso, que pode incluir uma ou mais unidades NAL.

[058] As unidades NAL não VCL podem incluir unidades NAL de conjunto de parâmetros e unidades NAL SEI, entre outras Os conjuntos de parâmetros podem conter informação de cabeçalho de nível de sequência em conjuntos de parâmetros de sequência (PPS)). Com os conjuntos de parâmetros (por exemplo, PPS e SPS), a informação de mudança infrequente não precisa ser repetida para cada sequência ou imagem, dessa forma, a eficiência da codificação pode ser aperfeiçoada. Adicionalmente, o uso de conjuntos de parâmetros pode permitir a transmissão fora de banda de informação de cabeçalho importante, evitando a necessidade de transmissões redundantes para resiliência de erro. Nos exemplos de transmissão fora de banda, as unidades NAL de conjunto de parâmetros podem ser transmitidas em um canal diferente de outras unidades NAL, tal como unidades NAL SEI.

[059] A Informação de Aperfeiçoamento Suplementar (SEI) pode conter informação que não é necessária para a decodificação de amostras de imagens codificadas das unidades NAL VCL, mas pode auxiliar nos processos relacionados com a decodificação, exibição, resiliência de erro e para outras finalidades. As mensagens SEI podem ser contidas em unidades NAL não VCL. As mensagens SEI são a parte normativa de algumas especificações de padrão, e, dessa forma, nem sempre são obrigatórias para implementação de decodificador em conformidade com o padrão. As mensagens SEI podem ser mensagens SEI de nível de sequência ou mensagens SEI de nível de imagem. Algumas informações de nível de sequência podem estar contidas nas mensagens SEI, tal como mensagens SEI de informação de escalabilidade no exemplo SVC e mensagens SEI de informação de escalabilidade de visualização em MVC. Essas mensagens SEI ilustrativas podem portar informação, por exemplo, sobre a extração de pontos de operação e características dos pontos de operação. Adicionalmente, a unidade de encapsulamento 150 pode formar um arquivo de manifesto, tal como um descritor de apresentação de mídia (MPD) que descreve as características das representações. A unidade de encapsulamento 150 pode formatar MPD de acordo com a linguagem extensível de marcação (XML).

[060] A unidade de encapsulamento 150 pode fornecer dados para uma ou mais representações do conteúdo de multimídia, juntamente com o arquivo de manifesto (por exemplo, MPD) para a interface de saída 152. A interface de saída 152 pode compreender uma interface de rede ou uma interface para escrever em um meio de armazenamento, tal como a interface de barramento serial universal (USB), uma escritora ou gravador CD ou DVD, uma interface para meio de armazenamento magnético ou flash, ou outras interfaces para o armazenamento ou transmissão de dados de mídia. A unidade de encapsulamento 150 pode fornecer dados de cada uma das representações de conteúdo de multimídia para a interface de saída 152, que pode enviar os dados para o dispositivo servidor 160 através de uma transmissão de rede ou meio de armazenamento. No exemplo da figura 4, o dispositivo servidor 160 inclui o meio de armazenamento 162 que armazena vários conteúdos de multimídia 164, cada um incluindo um arquivo de manifesto respectivo 166 e uma ou mais representações 168A-168N (representações 168). Em alguns exemplos, a interface de saída 152 também pode enviar dados diretamente para a rede 174.

[061] Em alguns exemplos, as representações 168 podem ser separadas em conjuntos de adaptação Isso, vários subconjuntos de representações 168 podem incluir conjuntos comuns respectivos das características, tal como codec, perfil e nível, resolução, número de visualizações, formato de arquivo para segmentos, informação de tipo de texto que pode identificar uma linguagem ou outras características de texto a serem exibidas com a representação e/ou dados de áudio a serem decodificados e apresentados, por exemplo, por alto falantes, informação de ângulo de câmera que pode descrever um ângulo de câmera ou perspectiva de câmera no mundo real de uma cena para representações no conjunto de adaptação, informação de classificação que descreve a adequação do conteúdo para audiências específicas, ou similares.

[062] O arquivo de manifesto 166 pode incluir dados indicativos de subconjuntos das representações 168 correspondentes aos conjuntos de adaptação em particular, além de características comuns para os conjuntos de adaptação. O arquivo de manifesto 166 também pode incluir dados representativos de características individuais, tal como taxas de bit, para representações individuais dos conjuntos de adaptação. Dessa forma, um conjunto de adaptação pode fornecer uma adaptação de largura de banda de rede simplificada. As representações em um conjunto de adaptações podem ser indicadas utilizando-se elementos criança de um elemento de conjunto de adaptações do arquivo manifesto 166.

[063] O dispositivo servidor 160 inclui a unidade de processamento de solicitação 170 e interface de rede 172. Em vários exemplos, o dispositivo servidor 160 pode incluir uma pluralidade de interfaces de rede. Adicionalmente, toda ou qualquer uma das características do dispositivo servidor 160 podem ser implementadas em outros dispositivos de uma rede de distribuição de conteúdo, tal 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 temporariamente dados de conteúdo de multimídia 164 e incluir componentes que se conformam substancialmente aos do dispositivo servidor 160. Em geral, a interface de rede 172 é configurada para enviar e receber dados através da rede 174.

[064] A unidade de processamento de solicitação 170 é configurada para receber solicitações de rede dos dispositivos de cliente, tal como o dispositivo de cliente 180, para dados do meio de armazenamento 162. Por exemplo, a unidade de processamento de solicitação 170 pode implementar o protocolo de transferência de hipertexto (HTTP) versão 1.1, como descrito em RFC 2616, "Hypertext Transfer Protocol - HTTP/1.1", por R. Fielding et al., Network Working Group, IETF, junho de 1999. Isso é, a unidade de processamento de solicitação 170 pode ser configurada para receber solicitações HTTP GET ou GET parciais e fornecer dados do conteúdo de multimídia 164 em resposta às solicitações. As solicitações podem especificar um segmento de uma das representações 168, por exemplo, utilizando um URL do segmento. Em alguns exemplos, as solicitações também podem especificar uma ou mais faixas de byte do segmento, compreendendo, assim, solicitações GET parciais. A unidade de processamento de solicitação 170 pode ser adicionalmente configurada para servir solicitações HTTP HEAD para fornecer dados de cabeçalho de um segmento de uma das representações 168. Em qualquer caso, a unidade de processamento de solicitação 170 pode ser configurada para processar as solicitações para fornecer dados solicitados para um dispositivo solicitante, tal como o dispositivo de cliente 180.

[065] Adicionalmente ou alternativamente, a unidade de processamento de solicitação 170 pode ser configurada para distribuir dados de mídia através de um protocolo de difusão ou multidifusão, tal como eMBMS. O dispositivo de preparação de conteúdo 140 pode criar segmentos DASH e/ou subsegmentos substancialmente da mesma forma que a que foi descrita, mas o dispositivo servidor 160 pode distribuir esses segmentos ou subsegmentos utilizando eMBMS ou outro protocolo de transporte de rede de difusão ou multidifusão. Por exemplo, a unidade de processamento de solicitação 170 pode ser configurada para receber uma solicitação de adesão ao grupo de multidifusão do dispositivo de cliente 180. Isso é, o dispositivo servidor 160 pode anunciar um endereço de protocolo de Internet (IP) associado com um grupo de multidifusão para dispositivos de cliente, incluindo o dispositivo de cliente 180, associado com o conteúdo de mídia em particular (por exemplo, uma difusão de um evento ao vivo). O dispositivo de cliente 180, por sua vez, pode submeter uma solicitação de adesão ao grupo de multidifusão. Essa solicitação pode ser propagada através da rede 174, por exemplo, roteadores criando a rede 174, de modo que os roteadores sejam obrigados a direcionar o tráfego destinado para o endereço IP associado com o grupo de multidifusão para os dispositivos de cliente assinantes, tal como o dispositivo de cliente 180.

[066] Como ilustrado no exemplo da figura 4, o conteúdo de multimídia 164 inclui o arquivo de manifesto 166, que pode corresponder a uma descrição de apresentação de mídia (MPD). No caso de uma MPD, correspondendo ao padrão DASH, o arquivo de manifesto 166 também pode incluir diretivas sobre quais métricas um cliente pode coletar e reportar para um servidor especificado. O arquivo de manifesto 166 pode conter descrições sobre diferentes representações alternativas 168 (por exemplo, serviços de vídeo com qualidades diferentes) e a descrição pode incluir, por exemplo, informação de codec, um valor de perfil, um valor de nível, uma taxa de bits, e outras características descritivas das representações 168. O dispositivo de cliente 180 pode recuperar a MPD de uma apresentação de mídia para determinar como acessar os segmentos das representações 168.

[067] Em particular, a unidade de recuperação 192 pode recuperar os dados de configuração (não ilustrados) do dispositivo de cliente 180 para determinar as capacidades de decodificação do decodificador de vídeo 188 e capacidades de interpretação da saída de vídeo 184. Os dados de configuração também podem incluir toda ou qualquer uma dentre as preferências de linguagem selecionadas por um usuário do dispositivo de cliente 180, uma ou mais perspectivas de câmera correspondentes às preferências de profundidade apresentadas pelo usuário do dispositivo de cliente 180, e/ou uma preferência de classificação selecionada pelo usuário do dispositivo de cliente 180. A unidade de recuperação 192 pode compreender, por exemplo, um navegador de rede ou um cliente de mídia configurado para submeter solicitações HTTP GET e GET parcial. A unidade de recuperação 192 pode corresponder a instruções de software executadas por um ou mais processadores ou unidades de processamento (não ilustradas) do dispositivo de cliente 180. Em alguns exemplos, toda ou partes da funcionalidade descrita com relação à unidade de recuperação 192 pode ser implementada em hardware, ou uma combinação de hardware, software e/ou firmware, onde hardware necessário pode ser fornecido para executar as instruções para software ou firmware.

[068] A unidade de recuperação 192 pode comparar as capacidades de decodificação e interpretação do dispositivo de cliente 180 com as capacidades das representações 168 indicadas pela informação do arquivo de manifesto 166. A unidade de recuperação 192 pode recuperar inicialmente pelo menos uma parte do arquivo de manifesto 166 para determinar as características das representações 168. Por exemplo, a unidade de recuperação 192 pode solicitar uma parte do arquivo de manifesto 166 que descreve as características de um ou mais conjuntos de adaptação. A unidade de recuperação 192 pode selecionar um subconjunto de representações 168 (por exemplo, um conjunto de adaptação) possuindo características que podem ser satisfeitas pelas capacidades de codificação e interpretação do dispositivo de cliente 180. A unidade de recuperação 192 pode, então, determinar as taxas de bits para as representações no conjunto de adaptação, determinar uma quantidade atualmente disponível de largura de banda de rede, e recuperar os segmentos a partir de uma das representações possuindo uma taxa de bit que pode ser satisfeita pela largura de banda de rede.

[069] Em geral, as representações de taxa de bit mais altas podem resultar em uma reprodução de vídeo de qualidade melhor, enquanto representações de taxa de bit menores podem fornecer uma reprodução de vídeo de qualidade suficiente quando a largura de banda de rede disponível é reduzida. De acordo, quando a largura de banda de rede disponível é relativamente alta, a unidade de recuperação 192 pode recuperar os dados das representações de taxa de bit relativamente altas, ao passo que quando a largura de banda de rede disponível é baixa, a unidade de recuperação 192 pode recuperar os dados das representações de taxa de bits relativamente baixa. Dessa forma, o dispositivo de cliente 180 pode transmitir dados de multimídia através da rede 174 enquanto também se adapta à disponibilidade de largura de banda de rede mutável da rede 174.

[070] Adicionalmente ou alternativamente, a unidade de recuperação 192 pode ser configurada para receber dados de acordo com um protocolo de rede de difusão ou multidifusão, tal como MBMS, eMBMS, ou multidifusão IP. Em tais exemplos, a unidade de recuperação 192 pode submeter uma solicitação de adesão a um grupo de rede de multidifusão associado com o conteúdo de mídia em particular. Depois de se unir ao grupo de multidifusão, a unidade de recuperação 192 pode receber dados do grupo de multidifusão sem solicitações adicionais emitidas para o dispositivo servidor 160 ou dispositivo de preparação de conteúdo 140. A unidade de recuperação 192 pode submeter uma solicitação para deixar o grupo de multidifusão quando os dados do grupo de multidifusão não são mais necessários, por exemplo, para interromper a reprodução ou para mudar canais para um grupo de multidifusão diferente.

[071] De acordo com as técnicas dessa descrição, a unidade de recuperação 192 pode incluir um aplicativo de transmissão (por exemplo, um cliente DASH) e uma unidade de middleware. A unidade de middleware pode ser configurada para receber medições de qualidade de experiência (QoE) do cliente DASH e distribuir as medições de QoE, juntamente com os reportes de recepção eMBMS para, por exemplo, o dispositivo servidor 160. Isso é, o dispositivo de cliente 180 pode corresponder ao UE 106', 106" das figuras 2, 3 e o dispositivo servidor 160 pode corresponder ao servidor de provisionamento e BMSC 104',104" das figuras 2, 3. Apesar de não ilustrado na figura 4, em alguns exemplos, o sistema 130 pode incluir adicionalmente um servidor de coleta de métrica de qualidade DASH, ao qual o cliente DASH e/ou a unidade de middleware pode reportar as medições de QoE DASH, como discutido com relação à figura 3 acima.

[072] A interface de rede 194 pode receber e fornecer dados dos segmentos de uma representação selecionada para a unidade de recuperação 192, que pode, por sua vez, fornecer os segmentos para a unidade de descapsulação 190. A unidade de descapsulação 190 pode descapsular elementos de um arquivo de vídeo em sequências PES constituintes, desempacotar as sequências PES para recuperação dos dados codificados, e enviar os dados codificados para o decodificador de áudio 186 ou decodificador de vídeo 188, dependendo de se os dados codificados são parte de uma sequência de áudio ou vídeo, por exemplo, como indicado pelos cabeçalhos de pacote PES da sequência. O decodificador de áudio 186 decodifica os dados de áudio codificados e envia os dados de áudio decodificados para a saída de áudio 182, enquanto o decodificador de vídeo 188 decodifica os dados de video codificados e envia os dados de vídeo decodificados, que podem incluir uma pluralidade de visualizações de uma sequência, para a saída de vídeo 184.

[073] O codificador de vídeo 148, o decodificador de vídeo 188, o codificador de áudio 146, o decodificador de áudio 186, a unidade de encapsulamento 150, a unidade de recuperação 192, a unidade de processamento de solicitação 170, e a unidade de descapsulação 190 podem, cada uma, ser implementadas como qualquer um dentre uma variedade de conjuntos de circuitos de processamento fixos e/ou programáveis adequados, como aplicável, tal como um ou mais microprocessadores, processadores de sinal digital (DSPs), circuitos integrados específicos de aplicativo (ASICs), conjuntos de porta programáveis em campo (FPGAs), conjunto de circuitos de lógica discreta, software, hardware, firmware ou qualquer combinação dos mesmos. Cada codificador de vídeo 148 e decodificador de vídeo 188 pode ser incluído em um ou mais codificadores ou decodificadores, qualquer um dos quais pode ser integrado como parte de um codificador/decodificador de vídeo (CODEC) combinado. Da mesma forma, cada codificador de áudio 146 e decodificador de áudio 186 pode ser incluído em um ou mais codificadores ou decodificadores, qualquer um dos quais pode ser integrado como parte de um CODEC combinado. Um aparelho incluindo o codificador de vídeo 148, o decodificador de vídeo 188, o codificador de áudio 146, o decodificador de áudio 186, a unidade de encapsulamento 150, a unidade de recuperação 192, a unidade de processamento de solicitação 170 e/ou a unidade de descapsulação 10 pode compreender um circuito integrado, um microprocessador, e/ou um dispositivo de comunicação sem fio, tal como um telefone celular.

[074] O dispositivo de cliente 180, o dispositivo servidor 160 e/ou o dispositivo de preparação de conteúdo 140 podem ser configurados para operar de acordo com as técnicas dessa descrição. Para fins de exemplo, essa descrição descreve essas técnicas com relação ao dispositivo de cliente 180 e dispositivo servidor 160. No entanto, deve-se compreender que o dispositivo de preparação de conteúdo 140 pode ser configurado para realizar essas técnicas, em vez do (ou em adição a) dispositivo servidor 160.

[075] A unidade de encapsulamento 150 pode formar unidades NAL compreendendo um cabeçalho que identifica um programa ao qual a unidade NAL pertence, além de uma carga útil, por exemplo, dados de áudio, dados de vídeo, ou dados que descrevem a sequência de transporte ou programa à 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 os dados de vídeo em sua carga útil pode compreender vários níveis de detalhamento dos dados de vídeo. Por exemplo, uma unidade NAL pode compreender um bloco de dados de vídeo, uma pluralidade de blocos, uma fatia de dados de vídeo ou toda uma imagem de dados de vídeo. A unidade de encapsulamento 150 pode receber dados de vídeo codificados a partir do codificador de vídeo 148 na forma de pacotes PES de sequências elementares. A unidade de encapsulamento 150 pode associar cada sequência elementar com um programa correspondente.

[076] A unidade de encapsulamento 150 também pode montar unidades de acesso a partir de uma pluralidade de unidades NAL. Em geral, uma unidade de acesso pode compreender uma ou mais unidades NAL para representar um quadro de dados de vídeo, além de dados de áudio correspondentes ao quadro quando tais dados de áudio estão disponíveis. Uma unidade de acesso inclui geralmente todas as unidades NAL para um momento de saída, por exemplo, todos os dados de áudio e vídeo para um momento. Por exemplo, se cada visualização possuir uma taxa de quadro de 20 quadros por segundo (fps), então, cada momento pode corresponder a um intervalo de tempo de 0,05 segundos. Durante esse intervalo de tempo, os quadros específicos para todas as visualizações da mesma unidade de acesso (o mesmo momento) podem ser reproduzidos simultaneamente. Em um exemplo, uma unidade de acesso pode compreender uma imagem codificada em um momento, que pode ser apresentada como uma imagem codificada primária.

[077] De acordo, uma unidade de acesso pode compreender todos os quadros de áudio e vídeo de um momento temporal comum, por exemplo, todas as visualizações correspondentes ao momento X. Essa descrição também se refere a uma imagem codificada de uma visualização particular como um "componente de visualização". Isso é, um componente de visualização pode compreender uma imagem codificada (ou quadro) para uma visualização em particular em um momento particular. De acordo, uma unidade de acesso pode ser definida como compreendendo todos os componentes de visualização de um momento temporal comum. A ordem de decodificação das unidades de acesso não precisa ser necessariamente a mesma que a ordem de saída ou exibição.

[078] Uma apresentação de mídia pode incluir uma descrição de apresentação de mídia (MPD), que pode conter descrições sobre diferentes representações alternativas (por exemplo, serviços de vídeo com qualidades diferentes) e a descrição pode incluir por exemplo, informação de codec, um valor de perfil, e um valor de nível. Uma MPD é um exemplo de um arquivo de manifesto, tal como o arquivo de manifesto 166. O dispositivo de cliente 180 pode recuperar a MPD de uma apresentação de mídia para determinar como acessar os fragmentos de filme de várias apresentações. Os fragmentos de filme podem estar localizados nas caixas de fragmentos de filme (caixas moof) dos arquivos de vídeo.

[079] O arquivo de manifesto 166 (que pode compreender, por exemplo, uma MPD) pode anunciar a disponibilidade dos segmentos das representações 168. Isso é, a MPD pode incluir informação indicando o tempo no relógio no qual um primeiro segmento de uma das representações 168 se torna disponível, além de uma informação indicando as durações dos segmentos dentro das representações 168. Dessa forma, a unidade de recuperação 192 do dispositivo de cliente 180 pode determinar quando cada segmento está disponível, com base no momento inicial além das durações dos segmentos anteriores a um segmento particular.

[080] Depois de a unidade de encapsulamento 150 ter montado as unidades NAL e/ou unidades de acesso em um arquivo de vídeo com base nos dados recebidos, a unidade de encapsulamento 150 passa o arquivo de vídeo para a interface de saída 152 para saída. Em alguns exemplos, a unidade de encapsulamento 150 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 152, em vez de enviar o arquivo de vídeo diretamente para o dispositivo de cliente 180. A interface de saída 152 pode compreender, por exemplo, um transmissor, um transceptor, um dispositivo para escrever dados para um meio legível por computador tal como, por exemplo, um acionador ótico, um acionador de meio magnético (por exemplo, uma 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 152 envia o arquivo de vídeo para um meio legível por computador, tal como, por exemplo, um sinal de transmissão, um meio magnético, um meio ótico, uma memória, um flash drive, ou outro meio legível por computador.

[081] A interface de rede 194 pode receber uma unidade NAL ou unidade de acesso através da rede 174 e fornecer a unidade NAL ou unidade de acesso para a unidade de descapsulação 190, através da unidade de recuperação 192. A unidade de descapsulação 190 pode descapsular um elemento de um arquivo de vídeo em sequências PES constituintes, desempacotar as sequências PES para recuperar os dados codificados, e enviar os dados codificados para o decodificador de áudio 186 ou decodificador de vídeo 188, dependendo de se os dados codificados são parte de uma sequência de áudio ou vídeo, por exemplo, como indicado pelos cabeçalhos de pacote PES da sequência. O decodificador de áudio 186 decodifica os dados de áudio codificados e envia os dados de áudio decodificados para a saída de áudio 182, enquanto que o decodificador de vídeo 188 decodifica os dados de vídeo codificados e envia os dados de vídeo decodificados, que podem incluir uma pluralidade de visualizações de uma sequência, para a saída de vídeo 184.

[082] A MPD inclui um elemento métrico que contém as métricas a serem coletadas, e os parâmetros de upload. Os parâmetros de upload incluem um elemento de reporte que pode ser expandido através do uso de valores específicos reporting@schemeIdUri. A seção 10.5 de 3GP-DASH 26.246, versão d00, especifica que URN a ser utilizado para Reporting@schemeIdUri deve ser "urn:3GPP:ns:PSS:DASH:QM10." 3GP-DASH também define a semântica da informação de esquema para o esquema de reporte de qualidade 3GP-DASH como segue:

[083] A figura 5 é um diagrama em bloco ilustrando um conjunto ilustrativo de componentes da unidade de recuperação 192 da figura 4, em maiores detalhes. Nesse exemplo, a unidade de recuperação 192 inclui unidade de middleware eMBMS 200, cliente DASH 212 e aplicativo de mídia 214. A unidade de middleware eMBMS 200 pode, geralmente, corresponder a MSDC 112', 112" das figuras 2, 3, enquanto o cliente DASH 212 pode corresponder ao cliente DASH 108', 108" das figuras 2 e 3.

[084] Nesse exemplo, a unidade de middleware eMBMS 200 inclui adicionalmente a unidade de recepção eMBMS 206, a memória cache 204, o servidor proxy/local 202, e a unidade de reporte de recepção 210. Nesse exemplo, a unidade de recepção eMBMS 206 é configurada para receber dados através de eMBMS, por exemplo, de acordo com a Distribuição de Arquivo através de Transporte Unidirecional (FLUTE), descrita em T. Paila et al., "FLUTE - File Delivery over Unidirectional Transport", Network Working Group, RFC 6726, novembro de 2012, disponível em tools.ietf.org/html/rfc6726, ou protocolo de Distribuição de Objeto em Tempo Real através de Transporte Unidirecional (ROUTE). Isso é, a unidade de recepção eMBMS 206 pode receber arquivos através da difusão a partir, por exemplo, do dispositivo servidor 160 da figura 4, que pode agir como um BM-SC.

[085] À medida que a unidade de middleware eMBMS 206 recebe os dados para os arquivos, a unidade de middleware eMBMS pode armazenar os dados recebidos na memória cache 204. A memória cache 204 pode compreender um meio de armazenamento legível por computador, tal como memória flash, um disco rígido, RAM ou qualquer outro meio de armazenamento adequado.

[086] O servidor proxy/local 202 pode agir como um servidor HTTP para o cliente DASH 212. Por exemplo, o middleware pode modificar o arquivo MPD ou outro arquivo de manifesto para o cliente DASH 212. Middleware 200 anunciaria momentos de disponibilidade ajustados para os segmentos no arquivo MPD, além de hiperlinks de onde os segmentos podem ser recuperados localmente. Esses hiperlinks podem incluir um prefixo de endereço localhost correspondendo ao dispositivo de cliente 180 da figura 4 (por exemplo, 127.0.0.1 para IPv4). Dessa forma, o cliente DASH 212 pode solicitar os segmentos do servidor HTTP local 202 utilizando solicitações HTTP GET ou GET parcial. Por exemplo, para um segmento disponível a partir do link http://127.0.0.1/rep1/seg3, o cliente DASH 212 pode construir uma solicitação HTTP GET que inclui uma solicitação para http://127.0.0.1/rep1/seg3, e submeter a solicitação para o servidor proxy/local 202. O servidor proxy/local 202 pode recuperar os dados solicitados da memória cache 204 e fornecer os dados para o cliente DASH 212 em resposta a tais solicitações. Alternativamente, a unidade de middleware eMBMS 200 não precisa modificar os URLs na MPD e agir como um proxy. As solicitações destinadas ao Servidor DASH 170 são interceptadas pela unidade de middleware eMBMS 200 e servidas a partir da memória cache local.

[087] De acordo com as técnicas dessa descrição, o servidor HTTP proxy/local 202 também inclui a unidade de recebimento de métricas de QoE DASH 208. A unidade de recebimento de métricas de QoE DASH 208 é geralmente configurada para interceptar (no caso de proxy, favor notar que o servidor proxy/local 22 pode, opcionalmente, passar reportes para um servidor de medição DASH) ou receber (quando agindo como um servidor local) reportes DASH do cliente DASH, por exemplo, aceitando os comandos de postagem HTTP. O reporte é então enviado para a unidade de reporte de recepção 210, que, então, pode reportar as métricas de QoE DASH em nome do cliente DASH 212 para um dispositivo servidor e/ou pode incluir o reporte de medição de QoE DASH e um reporte de recepção. Por exemplo, as métricas de QoE DASH podem receber as métricas de QoE do cliente DASH 212. Isso é, o servidor proxy/local 202 pode ser configurado para receber os comandos HTTP POST do cliente DASH 212 incluindo as métricas de QoE DASH de acordo com uma descrição de apresentação de mídia (MPD) ou outro arquivo de manifesto. Adicionalmente, a unidade de reporte de recepção 210 reporta a recepção de acordo com, por exemplo, eMBMS. Em alguns exemplos, a unidade de reporte de recepção 210 envia um reporte singular incluindo ambas métricas de QoE DASH e reportes de recepção eMBMS. Em outros exemplos, a unidade de reporte de recepção 210 envia reportes separados para os reportes de recepção eMBMS e métricas de QoE DASH.

[088] Depois do recebimento de um reporte de medição de QoE DASH do cliente DASH 212, a unidade de reporte de recepção 210 pode reportar as métricas de QoE DASH para um dispositivo servidor, juntamente com os reportes de recepção relacionados com um protocolo pelo qual a unidade de middleware eMBMS 200 reporta a recepção de arquivos encapsulando os dados DASH. Adicionalmente, em alguns exemplos, um ou ambos a unidade de middleware eMBMS 200 e/ou o cliente DASH 212 podem ser configurados para reportar também as métricas de QoE DASH para um servidor de métricas DASH dedicado, como discutido com relação à figura 3 acima.

[089] O dispositivo servidor 160 (figura 1) também pode incluir uma função BMSC que distribui um anúncio de serviço para a unidade de middleware eMBMS 200. Como parte dessa invenção, o anúncio de serviço pode incluir adicionalmente diretivas sobre o tipo e conteúdo do reporte de medição de QoE DASH. Por exemplo, o fragmento de Procedimento de Distribuição Associada (ADP) do anúncio de serviço pode inclui novos campos e elementos que descrevem as métricas desejadas para o reporte de QoE DASH, além de outros parâmetros. Uma implementação ilustrativa é descrita posteriormente nas figuras 9 e 10 abaixo. Em um sentido mais geral, as diretivas de coleta de QoE DASH podem ser distribuídas através de outros meios, por exemplo, OMA DM, um arquivo de configuração, a MPD original propriamente dita, ou qualquer outro meio.

[090] A unidade de middleware eMBMS 200 pode, então, comunicar as diretivas acima para o cliente DASH 212. Um método de comunicação dessas diretivas é que a unidade de middleware eMBMS 200 pode modificar a MPD hospedada localmente (exceto no caso onde a MPD original porta as diretivas, caso no qual a unidade de middleware eMBMS 200 não precisa modificar a MPD) para refletir os parâmetros de coleta de métricas obtidos a partir do servidor 160 da figura 4.

[091] Em outro exemplo, a unidade de middleware eMBMS 200 pode modificar a MPD para coletar as métricas desejadas ou um superconjunto de métricas, e para sempre reportar para a unidade de middleware eMBMS 200. A unidade de middleware eMBMS 200 pode então reduzir as métricas para o conjunto solicitado pelo servidor 160 e reportar com a probabilidade solicitada pelo servidor 160.

[092] Em outro exemplo adicional, o servidor 160 instrui a unidade de middleware eMBMS 200 a coletar os reportes de recepção de acordo com as diretivas de coleta que incluem uma probabilidade de coleta de reporte de recepção (parâmetro samplingPercentage no fragmento ADP atual). A diretiva de Coleta de QoE DASH enviada para a unidade de middleware eMBMS 200 pode, então, incluir uma probabilidade de coleta independente ou uma probabilidade de coleta condicional. A probabilidade de coleta relativa indica a coleta condicional das medições de QoE DASH apenas quando o reporte de recepção está sendo coletado, por exemplo, se o parâmetro de percentual de amostragem de reporte de recepção é de 50% e a probabilidade de coleta condicional é de 50% também, então, os reportes de recepção são coletados para 50% das sessões, e reportes de medição DASH são coletados para 50% dessas sessões onde o reporte de recepção esta ativo. A probabilidade absoluta resultante de coleta para as medições de QoE DASH é então de 25%.

[093] A figura 6 é um diagrama conceitual ilustrando elementos do conteúdo de multimídia ilustrativo 220. O conteúdo de multimídia 220 pode corresponder ao conteúdo de multimídia 164 (figura 4), ou outro conteúdo de multimídia armazenado no meio de armazenamento 162. No exemplo da figura 6, o conteúdo de multimídia 220 inclui a descrição de apresentação de mídia (MPD) 222 e uma pluralidade de representações 224A-224N (representações 224). A representação 224A inclui dados de cabeçalho opcionais 226 e segmentos 228A-228N (segmentos 228), enquanto que a representação 224N inclui dados de cabeçalho opcionais 230 e segmentos 232A-232N (segmentos 232). A letra N é utilizada para designar o ultimo fragmento de filme em cada uma das representações 224 como uma questão de conveniência. Em alguns exemplos, pode haver números diferentes de fragmentos de filme entre as representações 224.

[094] A MPD 222 pode compreender uma estrutura de dados separada das representações 224. A MPD 222 pode corresponder ao arquivo de manifesto 166 da figura 4. Da mesma forma, as representações 224 podem corresponder às representações 168 da figura 4. Em geral, a MPD 222 pode incluir dados que geralmente descrevem as características das representações 224, tal como características de codificação e interpretação, conjuntos de adaptação, um perfil ao qual a MPD 222 corresponde, informação de tipo de texto, informação de ângulo de câmera, informação de classificação, informação de modo de trick (por exemplo, informação indicativa de representações que incluem subsequências temporais), e/ou informação para recuperação de períodos remotos (por exemplo, para inserção de anúncios alvo no conteúdo de mídia durante a reprodução).

[095] Os dados de cabeçalho 226, quando presentes, podem descrever as características dos segmentos 228, por exemplo, localizações temporais dos pontos de acesos randômico (RAPs, também referidos como pontos de acesso de sequência (SAPs)), quais dos segmentos 228 incluem pontos de acesso randômicos, desvios de byte para os pontos de acesso randômico dentro dos segmentos 228, localizadores de recurso uniforme (URLs) dos segmentos 228, ou outros aspectos dos segmentos 228. Os dados de cabeçalho 230, quando presentes, podem descrever características similares para os segmentos 232. Adicionalmente ou alternativamente, tais características podem ser totalmente incluídas na MPD 222.

[096] Os segmentos 228, 232 incluem uma ou mais amostras de vídeo codificado, cada uma das quais pode incluir quadros ou fatias de dados de vídeo. Cada uma das amostras de vídeo codificadas dos segmentos 228 pode possuir características similares, por exemplo, exigências de altura, largura e largura de banda. Tais características podem ser descritas por dados da MPD 222, apesar de tais dados não serem ilustrados no exemplo da figura 6. A MPD 222 pode incluir características como descrito pela Especificação 3GPP, com a adição de toda ou qualquer informação sinalizada descrita nessa descrição.

[097] Cada um dos segmentos 228, 232 pode ser associado com um localizador de recurso uniforme singular (URL). Dessa forma, cada um dos segmentos 228, 232 pode ser independentemente recuperável utilizando um protocolo de rede de transmissão, tal como DASH. Dessa forma, um dispositivo de destino, tal como um dispositivo de cliente 180 da figura 4, pode utilizar uma solicitação HTTP GET para recuperar os segmentos 228 ou 232. Em alguns exemplos, o dispositivo de cliente 180 pode utilizar as solicitações HTTP GET parciais para recuperar as faixas específicas de bytes dos segmentos 228 ou 232.

[098] De acordo com as técnicas dessa descrição, a MPD 222 pode incluir dados especificando as métricas a serem reportadas para um dispositivo servidor. Por exemplo, a MPD 222 pode incluir dados em conformidade com o que foi descrito com relação à figura 8 abaixo.

[099] A figura 7 é um diagrama em bloco ilustrando os elementos de um arquivo de vídeo ilustrativo 250, que pode corresponder a um segmento de uma representação, tal como um dos segmentos 228, 232 da figura 6. Cada um dos segmentos 228, 232 pode incluir dados que se conformam substancialmente à disposição dos dados ilustrada no exemplo da figura 7. O arquivo de dados 250 pode ser considerado como encapsulando um segmento. Como descrito acima, os arquivos de vídeo de acordo com o formato de arquivo de mídia de base ISO e extensões do mesmo armazenam dados em uma série de objetos, referidos como "caixas". No exemplo da figura 7, o arquivo de vídeo 250 inclui a caixa de tipo de arquivo (FTYP) 252, a caixa de filme (MOOV) 254, as caixas de índice de segmento (sidx) 262, as caixas de fragmento de filme (MOOF) 164, e a caixa de acesso randômico a fragmento de filme (MFRA) 266. Apesar de a figura 7 representar um exemplo de um arquivo de vídeo, deve-se compreender que outros arquivos de mídia podem incluir outros tipos de dados de mídia (por exemplo, dados de áudio, dados de texto temporizado ou similares) que são estruturados de forma similar aos dados do arquivo de vídeo 250, de acordo com o formato de arquivo de mídia de base ISO e suas extensões.

[0100] A caixa de tipo de arquivo (FTYP) 252 geralmente descreve um tipo de arquivo para o arquivo de vídeo 250. A caixa de tipo de arquivo 252 pode incluir dados que identificam uma especificação que descreve um melhor uso para o arquivo de vídeo 250. A caixa de tipo de arquivo 252 pode, alternativamente, ser colocada antes da caixa MOOV 254, das caixas de fragmento de filme 164, e/ou da caixa MFRA 266.

[0101] Em alguns exemplos, um Segmento, tal como arquivo de vídeo 250, pode incluir uma caixa de atualização MPD (não ilustrada) antes da caixa FTYP 252. A caixa de atualização MPD pode incluir a informação indicando que uma MPD correspondente a uma representação que inclui arquivo de vídeo 250 precisa ser atualizada, juntamente com a informação para atualização de MPD. Por exemplo, a caixa de atualização MPD pode fornecer uma URI ou URL para um recurso a ser utilizado para atualizar a MPD. Como outro exemplo, a caixa de atualização MPD pode incluir dados para atualização da MPD. Em alguns exemplos, a caixa de atualização MPD pode seguir imediatamente uma caixa de tipo de segmento (STYP) (não ilustrada) do arquivo de vídeo 250, onde a caixa STYP pode definir um tipo de segmento para o arquivo de vídeo 250. A figura 7 discutida em maiores detalhes abaixo, fornece informação adicional com relação à caixa de atualização MPD.

[0102] A caixa MOOV 254, no exemplo da figura 7, inclui a caixa de cabeçalho de filme (MVHD) 256, a caixa de faixa (TRAK) 258, e uma ou mais caixas de extensões de filme (MVEX) 260. Em geral, a caixa MVHD 256 pode descrever as características gerais do arquivo de vídeo 250. Por exemplo, a caixa MVHD 256 pode incluir dados que descrevem quando o arquivo de vídeo 250 foi originalmente criado, quando o arquivo de vídeo 250 foi modificado pela última vez, uma escala de tempo para o arquivo de vídeo 250, uma duração da reprodução do arquivo de vídeo 250, outros dados que geralmente descrevem o arquivo de vídeo 250.

[0103] A caixa TRAK 258 pode incluir dados para uma faixa do arquivo de vídeo 250. A caixa TRAK 258 pode incluir uma caixa de cabeçalho de faixa (TKHD) que descreve as características da faixa correspondendo à caixa TRAK 258. Em alguns exemplos, a caixa TRAK 258 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 264, que podem ser referidos pelos dados da caixa TRAK 258 e/ou caixas sidx 262.

[0104] Em alguns exemplos, o arquivo de vídeo 250 pode incluir mais de uma faixa. De acordo, a caixa MOOV 254 pode incluir um número de caixas TRAK igual ao número de faixas no arquivo de vídeo 250. A caixa TRAK 258 pode descrever as características de uma faixa correspondente do arquivo de vídeo 250. Por exemplo, a caixa TRAK 258 pode descrever a informação temporal e/ou espacial para a faixa correspondente. Uma caixa TRAK similar à caixa TRAK 258 da caixa MOOV 254 pode descrever as características de uma faixa de conjunto de parâmetros, quando a unidade de encapsulamento 150 (figura 6) inclui uma faixa de conjunto de parâmetros em um arquivo de vídeo, tal como o arquivo de vídeo 250. A unidade de encapsulamento 150 pode sinalizar a presença das mensagens SEI de nível de sequência na faixa de conjunto de parâmetros dentro da caixa TRAK descrevendo a faixa de conjunto de parâmetros.

[0105] As caixas MVEX 260 podem descrever as características dos fragmentos de filme correspondentes 264, por exemplo, para sinalizar que o arquivo de vídeo 250 inclui fragmentos de filme 264, em adição aos dados de vídeo incluídos na caixa MOOV, se houver algum. No contexto de transmissão de dados de vídeo, as imagens de vídeo codificadas podem ser incluídas nos fragmentos de filme 264 em vez de na caixa MOOV 254. De acordo, todas as amostras de vídeo codificadas podem ser incluídas nos fragmentos de filme 264, em vez de na caixa MOOV 254.

[0106] A caixa MOOV 254 pode incluir várias caixas MVEX 260 iguais ao número de fragmentos de filme 264 no arquivo de vídeo 250. Cada uma das caixas MVEX 260 pode descrever as características de um fragmento correspondente dentre os fragmentos de filme 264. Por exemplo, cada caixa MVEX pode incluir uma caixa de cabeçalho de extensões de filme (MEHD) que descreve uma duração temporal para o fragmento correspondente dentre os fragmentos de filme 264.

[0107] Como notado acima, a unidade de encapsulamento 150 da figura 4 pode armazenar um conjunto de dados de sequência em uma amostra de vídeo que não inclui os dados de vídeo codificados reais. Uma amostra de vídeo pode corresponder geralmente a uma unidade de acesso, que é uma representação de uma imagem codificada em um momento específico. No contexto de AVC, a imagem codificada inclui uma ou mais unidades NAL VCL que contêm a informação para a construção de todos os pixels da unidade de acesso e outras unidades NAL não VCL, tal como as mensagens SEI. De acordo, a unidade de encapsulamento 150 pode incluir um conjunto de dados de sequência, que pode incluir mensagens SEI de nível de sequência, em um dos fragmentos de filme 264. A unidade de encapsulamento 150 pode sinalizar adicionalmente a presença de um conjunto de dados de sequência e/ou mensagens SEI de nível de sequência como estando presentes em um dos fragmentos de filme 264 dentro de uma das caixas MVEX 260 correspondentes a um dos fragmentos de filme 264.

[0108] As caixas SIDX 262 são elementos opcionais do arquivo de vídeo 250. Isso é, os arquivos de vídeo em conformidade com o formato de arquivo 3GPP, ou outros formatos de arquivo, não incluem necessariamente as caixas SIDX 262. De acordo com o exemplo do formato de arquivo 3GPP, uma caixa SIDX pode ser utilizada para identificar um subsegmento de um segmento (por exemplo, um segmento contido dentro do arquivo de vídeo 250). O formato de arquivo 3GPP define um subsegmento como "um conjunto autocontido de uma ou mais caixas de fragmento de filme consecutivas com caixas de Dados de Mídia correspondentes e uma Caixa de Dados de Mídia contendo dados referidos por uma Caixa de Fragmento de Filme deve seguir essa caixa de Fragmento de Filme e preceder a próxima caixa de Fragmento de Filme contendo informação sobre a mesma faixa." O formato de arquivo 3GPP também indica que uma caixa SIDX "contém uma sequência de referências a subsegmentos do (sub)segmento documentado pela caixa. Os subsegmentos referenciados são contíguos em tempo de apresentação. De forma similar, os bytes referidos pela caixa de Índice de Segmento são sempre contíguos dentro do segmento. O tamanho referido fornece a contagem do número de bytes no material referenciado".

[0109] As caixas SIDX 262 geralmente fornece informação representativa de um ou mais subsegmentos de um segmento incluído no arquivo de vídeo 250. Por exemplo, tal informação pode incluir tempos de reprodução nos quais os subsegmentos começam e/ou terminam, desvios de byte para os subsegmentos, se os subsegmentos incluem (por exemplo, começam com) um ponto de acesso à sequência (SAP), um tipo para o SAP (por exemplo, se o SAP é uma imagem de atualização instantânea de decodificador (IDR), uma imagem de acesso randômico liberado (CRA), uma imagem de acesso a link interrompido (BLA), ou similar), uma posição do SAP (em termos de tempo de reprodução e/ou desvio de byte) no subsegmento, e similares.

[0110] Os fragmentos de filme 264 podem incluir uma ou mais imagens de vídeo codificadas. Em alguns exemplos, os fragmentos de filme 264 podem incluir um ou mais grupos de imagens (GOPs), cada um dos quais pode incluir um número de imagens de vídeo codificadas, por exemplo, quadros ou imagens. Adicionalmente, como descrito acima, os fragmentos de filme 264 podem incluir conjuntos de dados de sequência em alguns exemplos. Cada um dos fragmentos de filme 264 pode incluir uma caixa de cabeçalho de fragmento de filme (MFHD, não ilustrado na figura 7). A caixa MFHD pode descrever as características do fragmento de filme correspondente, tal como um número de sequência no arquivo de filme. Os fragmentos de filme 264 podem ser incluídos em ordem de número de sequência no arquivo de vídeo 250.

[0111] A caixa MFRA 266 pode descrever os pontos de acesso randômicos dentro dos fragmentos de filme 264 do arquivo de vídeo 250. Isso pode auxiliar na realização dos modos de trick, tal como realização de buscas por localizações temporais particulares (isso é, tempos de reprodução) dentro de um segmento encapsulado pelo arquivo de vídeo 250. A caixa MFRA 266 é geralmente opcional e não precisa ser incluída nos arquivos de vídeo, em alguns exemplos. Da mesma forma, um dispositivo de cliente, tal como o dispositivo de cliente 180 da figura 4, não precisa, necessariamente, fazer referência à caixa MFRA 266 para decodificar e exibir corretamente os dados de vídeo do arquivo de vídeo 250. A caixa MFRA 266 pode incluir várias caixas de acesso randômico a fragmento de faixa (TFRA) (não ilustradas) igual ao número de faixas do arquivo de vídeo 250, ou, em alguns exemplos, igual ao número de faixas de mídia (por exemplo, faixas non-hint) do arquivo de vídeo 250.

[0112] Em alguns exemplos, os fragmentos de filme 264 podem incluir um ou mais pontos de acesso de sequência (SAPs), tal como imagens IDR. Da mesma forma, a caixa MFRA 266 pode fornecer indicações sobre localizações, dentro do arquivo de vídeo 250, dos SAPs. De acordo, uma subsequência temporal de arquivo de vídeo 250 pode ser formada a partir dos SAPs do arquivo de vídeo 250. A subsequência temporal também pode incluir outras imagens, tal como quadros P e/ou quadros B que dependem de SAPs. Os quadros e/ou fatias da subsequência temporal podem ser dispostos dentro dos segmentos de modo que os quadros/fatias da subsequência temporal que dependem de outros quadros/fatias da subsequência possam ser decodificados adequadamente. Por exemplo, na disposição hierárquica dos dados, os dados utilizados para previsão de outros dados também podem ser incluídos na subsequência temporal.

[0113] A figura 8 é um diagrama conceitual ilustrando dados ilustrativos 280 que podem ser incluídos em um arquivo de manifesto, tal como a descrição de apresentação de mídia (MPD) de DASH, de acordo com as técnicas dessa descrição. Nesse exemplo, a MPD pode incluir um ou mais elementos de métrica 282 na caixa MPDtype. Os limites 3GP-DASH existentes suportam uma ocorrência do elemento de métrica.

[0114] Adicionalmente, a MPD inclui uma lista de atributos de MetricsType 284, que especifica as métricas 286 a serem coletadas (e também pode incluir parâmetros de coleta, por exemplo, em parênteses). A lista de atributos MetricsType 284 também pode incluir um ou mais elementos de Reporte 288. Cada elemento de Reporte pode incluir um atributo especificando um SchemeIdURI 290, que pode ser um nome de recurso uniforme (URN) como definido em 3GP-DASH. Esse elemento SchemeIdURI 290 pode incluir dados estruturados adicionados como elementos ou atributos de extensão em um namespace separado. O valor do elemento SchemeIdURI 290 pode especificar um identificador de um servidor ao qual se reportar.

[0115] Ademais, a MPD inclui zero ou mais elementos de Faixa 292 para o elemento MetricsType. Cada elemento de faixa 292 inclui geralmente dados indicando quando coletar as métricas de QoE. Se o elemento de faixa 292 for omitido, uma unidade de cliente/middleware DASH pode determinar que as métricas são coletadas para toda a sessão. O elemento de Faixa 292, nesse exemplo, inclui o elemento de starttime 289 e o elemento de duração 291. Quando da transmissão de conteúdo de mídia ao vivo, o elemento starttime 289 pode especificar um tempo inicial com relação ao tempo inicial de disponibilidade para o conteúdo de mídia. O elemento de duração 291 pode especificar uma duração no tempo de reprodução para a faixa para a qual as métricas devem ser reportadas.

[0116] Dessa forma, os elementos de métrica 282 podem ser definidos no nível de raiz de MPD. Os possíveis valores de reporte SchemeIdURI 290 não são definidos em DASH MPEG. Em geral, SchemeIdURI 290 pode ser um localizador de recursos uniforme (URL), um nome de recurso uniforme (URN) ou outro valor de identificador. Um valor específico para 3GPP é definido em 3GP-DASH 26.247. O elemento de valor 285 do elemento de reporte 288 na lista de atributos é utilizado para uma lista de parâmetros. O elemento ID 287 do elemento de reporte 288 identifica os esquemas de reporte equivalentes onde apenas um dentre múltiplos schemeIdURIs de reporte precisa ser considerado, se vários desses elementos possuírem o mesmo ID.

[0117] A seção 10.5 de 3GP-DASH 26.247, versão d00, especifica uma sintaxe XML (linguagem extensível de marcação) da informação de esquema para o esquema de reporte de qualidade 3GP-DASH como segue: <?xml version = "1.0"?> <xs:schema targetNamespace="urn:3GPP:ns:PSS:AdaptiveHTTPStreaming:2009 :qm" attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs=http://www.w3.org/2 0 01/XMLSchema xmlns:xlink=http://www.w3.org/1999/xlink xmlns:="urn:3GPP:ns:PSS:AdaptiveHTTPStreaming:2009;=:qm "> <xs:annotation> <xs:appinfo>3GPP DASH Quality Reporting</xs:appinfo> <xs:documentation xml:lang="em"> Esse esquema define a informação de esquema de reporte de qualidade para 3GPP DASH. </xs:documentation> </xs:annotation> <xs:element name="ThreeGPPQualityReporting" Type="SimpleQualityReportingType"/> <xs:complexTypename="SimpleQualityReportingType"> <xs:attribute name="apn" type="xs:string" use="optional"/> <xs:attribute name="format" type="FormatType" use="optional"/> <xs:attribute name="samplePercentage" type="xs:double" use="optional"/> <xs:attribute name="reportingServer" type="xs:anyURI" use="required"/> <xs:attribute name="reportingInterval" type="xs:unsignedInt use="optional"/> <xs:complexType> <xs:simpleType name="FormatType"> <xs:restriction base="xs:string"> <xs:enumeration value="uncompressed"/> <xs:enumeration value="gzip"/> <xs:restriction> <xs:simpleType> <xs:schema>

[0118] O element "xmlns="urn:3GPP:ns:PSS:AdaptiveHTTPStreaming:2009:qm">" específica um namespace separado.

[0119] Como notado acima, a MPD de acordo com essa descrição permite a definição de múltiplos elementos de métrica. Se mais de um elemento de métrica for definido, então o cliente DASH (por exemplo, cliente DASH 212 da figura 5) pode criar um reporte de métrica distinto para cada elemento de métrica da MPD. Isso vai de encontro à especificação 3GP-DASH existente, que declara que "no máximo um elemento de métrica deve estar presente na MPD." Ademais, a especificação 3GP-DASH pode ser modificada de acordo com essa descrição, de modo que a especificação determine que os clientes DASH gerem um reporte de métrica por elemento de métrica da MPD.

[0120] A figura 9 é um diagrama conceitual ilustrando uma modificação ilustrativa 294 de uma descrição de procedimento de distribuição associada (ADPD) de acordo com as técnicas dessa descrição. De acordo com as técnicas dessa descrição, a modificação 294 de ADPD pode fornecer: * Um indicador 296A indicando se o reporte de QoE DASH deve ser coletado. a) Alternativamente: os atributos de QoE DASH podem ser adicionados dentro de um elemento, se o elemento estiver presente, então a coleta de QoE DASH está ativa. Nesse caso, o indicador de coleta 296A não é necessário. * Se o indicador 296A acima for configurado para verdadeiro, então, todos ou qualquer um dos atributos condicionais seguintes pode ser adicionado como parte da modificação 294: a) um indicador 296B indicando se a QoE DASH deve ser comprimida. b) uma lista de métricas 296C a serem coletadas. • Alternativamente, essas métricas podem ser especificadas nos dados de protocolo de descrição de sessão (SDP). c) um indicador 296D indicando se a coleta de QoE DASH deve ser sincronizada com o reporte de recepção. d) dados de percentual de amostragem de QoE DASH opcionais 296E.

[0121] Adicionalmente, a modificação 294 de ADPD pode incluir um indicador (não ilustrado) que indica para o middleware se a informação sobre as métricas existentes na MPD deve ser descartada/suprimida.

[0122] A figura 10 é um diagrama conceitual ilustrando um esquema alternativo para uma ADPD de acordo com as técnicas dessa descrição. Nesse exemplo, o elemento de tipo de procedimento de reporte 300 de ADPD inclui um elemento DASHQoEProcedure adicional 302. A presenta desse elemento DASHQoEProcedure adicional 302 aciona a coleta das medições de QoE DASH, especificadas no elemento de métricas DASH 304, como parte dos reportes de recepção. O elemento de métricas DASH 304, circulados na figura 10, podem ser tornados obrigatórios para se garantir que algumas métricas sejam definidas.

[0123] Como notado acima, pode haver um indicador, tal como o indicador DASH QoE Sync 306, indicando se a coleta de QoE DASH deve ser sincronizada com o reporte de recepção. Os comportamentos de sincronização podem ser definidos como segue, de acordo com o valor do indicador DASH QoE Sync 306: * Situação 1: o indicador DASH QoE Sync 306 é configurado para verdadeiro, nenhum outro percentual de amostragem é incluído para QoE DASH => se RR estiver ativo, coletar medição de QoE DASH. * Situação 2: o indicador DASH QoE Sync 306 é configurado para verdadeiro, um percentual de amostragem condicional 308 é incluído para QoE DASH. Isso implica em, se RR estiver ativo, middleware deve coletar as medições de QoE DASH de acordo com a probabilidade condicional indicada. a) Exemplo: O percentual de amostragem de reporte de recepção é de 50%; o percentual de amostragem de QoE DASH é de 50%, então, 50$ dos reportes de recepção de tempo são coletados; quando os reportes de recepção são coletados, os reportes de QoE DASH são coletados 50% do tempo (resultando em uma probabilidade de coleta de 25% para os reportes de medição de QoE DASH). * Situação 3: o indicador sync é configurado para falso, um percentual de amostragem é incluído para QoE DASH (ou o padrão é 100%). Isso implica que, independentemente da atividade RR, o middleware deve coletas as medições de QoE DASH na probabilidade indicada. Nessa alternativa, os reportes de recepção distribuídos para o servidor de reporte de recepção podem incluir apenas as métricas de QoE DASH.

[0124] Exemplos de agregação de reportes de recepção e reportes de medição de QoE DASH são descritos abaixo. Em alguns exemplos, os reportes de recepção eMBMS e reportes de medição de QoE DASH são agregados em um único arquivo de registros utilizando o procedimento existente que faz uso de formato de arquivo de múltiplas partes/misturado.

[0125] Em um primeiro exemplo, o tipo de conteúdo dos reportes de recepção pode ser utilizado para diferenciar os dois tipos de reportes, por exemplo, texto/xml para os arquivos de registro de reporte de recepção e texto/xml-DASH para reportes DASH. De acordo com esse primeiro exemplo, o reporte pode ser formatado como ilustrado abaixo: POST/reporting/reception/directory Content-Length: xxx Content-Type: multipart/mixed; boundary=frontier Host: w.x.y.z.: port Connection: Keep-Alive --frontier Content-Type: text/xml LOG (eMBMS RR) --frontier Content-Type: text/xml-DASH LOG (reporte de Medição de QoE DASH) --frontier Etc.

[0126] Em um segundo exemplo, o mesmo tipo de conteúdo text/xml pode ser utilizado. O receptor pode reconhecer o tipo de reporte através do cabeçalho do arquivo xml. De acordo com esse segundo exemplo, o reporte pode ser formatado como ilustrado abaixo: POST/reporting/reception/directory Content-Length: xxx Content-Type: multipart/mixed; boundary=frontier Host: w.x.y.z:port Connection: Keep-Alive --frontier Content-Type: text/xml LOG (eMBMS RR) --frontier Content-Type: text/xml LOG (reporte de medição de QoE DASH) --frontier Etc.

[0127] Em outro exemplo adicional, os reportes de medição DASH podem ser embutidos nos reportes de recepção eMBMS como novos elementos do esquema de reporte de recepção MBMS.

[0128] Em um exemplo, considera-se que o indicador Sync esteja ligado. Pode ser recomendado que o indicador Sync esteja sempre configurado para 1 (isso é, ligado). Em algumas implementações, o atributo/elemento de indicador sync pode não ser parte do esquema considerando- se que as medições de QoE DASH sejam sempre coletadas no Sync com os reportes de recepção eMBMS. A medição de QoE DASH através da postagem do reporte de recepção pode estar ativa apenas se o reporte de recepção estiver ativo. Com o indicador sync LIGADO, um reporte de recepção agregado pode conter apenas os reportes de recepção eMBMS ou um misto de reportes de recepção eMBMS e reportes de medição de QoE DASH.

[0129] Em um exemplo, uma lista de atributos de métricas reproduz uma lista de diretivas fornecida em ADPD. Os elementos SchemeIDURI podem ser preenchidos como segue: * Indicador de compressão (segue a diretiva de compressão ADPD). * Percentual de amostragem (por exemplo, 100%, para receber sempre o reporte em middleware; middleware pode então decidir se mantém o relatório ou descarta de acordo com as diretivas de percentual de amostragem e indicador sync de ADPD). * Postagem URL (que pode apontar para o servidor HTTP do middleware, por exemplo, servidor proxy/local 202 da figura 5). * Intervalos podem ser opcionais (podem ser configurados para intervalos menores para garantir reportes menores e mais frequentes obtidos pelo middleware; os reportes mais frequentes podendo fornecer robustez no caso de quebras do cliente DASH e/ou middleware).

[0130] Em um exemplo, o elemento de Faixa pode ser excluído, de modo que haja sempre um reporte de QoE DASH para toda a sessão. Alternativamente, o elemento de Faixa pode ser incluído para especificar um período de tempo para o qual as métricas QoE devem ser reportadas.

[0131] A unidade de middleware (por exemplo, a unidade de middleware 200 da figura 5) pode modificar a MPD passada para o Cliente DASH de modo que o cliente DASH gere sempre os reportes de medição de QoE DASH que então posta para o middleware. No entanto, a unidade de middleware pode ser configurada para determinar de forma probabilística se reporta as métricas de QoE DASH recebidas. Isso é, as métricas de QoE DASH podem ser reportadas de acordo com a mesma probabilidade que a especificada em ADPD. Dessa forma, em alguns casos, o reporte de QoE DASH recebido pela unidade de middleware a partir do cliente DASH pode ser descartado, sem ser reportado para o servidor (isso é, em casos nos quais é determinado que não se reporte a recepção de acordo com a probabilidade ADPD).

[0132] A figura 11A é um diagrama conceitual ilustrando um desempenho ilustrativo das técnicas dessa descrição. Nesse exemplo, é considerado que o indicador Sync discutido acima esteja ligado (isso é, tenha um valor de "verdadeiro"). O processo ilustrativo pode ser o que segue: * Um reporte de medição DASH é gerado no final de cada sessão de visualização DASH. * De acordo com a especificação 3GPP eMBMS, o middleware eMBMS toma uma decisão de registrar no final de uma sessão de recebimento/visualização. * No final da sessão eMBMS, o middleware coletou os registros de reporte de recepção: a) Assume-se que a decisão de registro do middleware seja de registrar. O middleware embute quaisquer reportes de medição DASH recebidos no reporte de recepção eMBMS utilizando o formato de arquivo mime de múltiplas partes. O reporte de recepção eMBMS, na forma do arquivo mime de múltiplas partes, misturado, é carregado utilizando o período de randomização especificado em ADPD. b) Assume-se que a decisão de registro de middleware seja de não registrar. Nesse caso, o reporte de recepção coletado no middleware é descartado. Quaisquer reportes recebidos subsequentemente do cliente DASH para a sessão também serão descartados.

[0133] Como uma alternativa, os reportes de Qualidade de QoE DASH podem ser gerados periodicamente. Isso pode fornecer uma maior confiabilidade no caso de quebra de cliente DASH. Os reportes ainda podem ser embutidos no arquivo de reporte de recepção mime de múltiplas partes. Um problema em potencial é que a decisão de se registrar ainda não foi tomada, de modo que a unidade de middleware pode precisar descartar os reportes posteriormente com base na decisão de registro de reporte de recepção.

[0134] Em um exemplo alternativo, é assumido que o indicador Sync esteja desligado. O reporte de medicado de QoE DASH através da postagem de reporte de recepção pode estar ativo independentemente de se a decisão é para se registrar o reporte de recepção eMBMS. O reporte de recepção agregado pode conter apenas reportes de recepção eMBMS, uma mistura de reportes de recepção eMBMS e reportes de medição de QoE DASH, ou apenas reportes de medição de QoE DASH. Isso ocorre em contraste com quando o indicador Sync está ligado, onde um arquivo de reporte de recepção carregado contém sempre um reporte de recepção 3GPP.

[0135] Com referência novamente ao exemplo da figura 8, a MPD pode ser igual quando o indicador Sync está desligado e quando o indicador Sync está ligado, como discutido acima. No entanto, o reporte de métricas de QoE DASH pode ser sempre coletado pelo cliente DASH, e a unidade de middleware pode determinar se inclui o reporte de métricas de QoE DASH em um arquivo de registro para o reporte de recepção.

[0136] A figura 11B é um diagrama conceitual ilustrando um exemplo do comportamento com recepção de unidifusão/difusão paralela de acordo com as técnicas dessa descrição. A unidade de middleware 200 pode servir os segmentos de clientes registrados eMBMS recebidos através de eMBMS e mudar para unidifusão (projeto MooD) se o serviço eMBMS não estiver mais disponível. Nesse caso, eMBMS pode agregar os reportes de recepção e reportes de medição de QoE DASH pela duração da sessão onde o serviço está ativo. Espera-se que a unidade de middleware 200 mantenha a sessão FLUTE ativa mesmo se o UE mudar para Unidifusão. Isso é, a unidade de middleware 200 pode continuar a coletar o reporte de recepção por todo o período de perda do conteúdo de difusão.

[0137] A figura 12 é um diagrama conceitual ilustrando um exemplo de comportamento com múltiplos clientes DASH. Por exemplo, no caso de arquiteturas softAP, múltiplos clientes DASH podem consumir conteúdo eMBMS a partir de um middleware comum. Em tais exemplos, o middleware pode coletar todos os reportes de medição DASH durante e até pouco depois do final da sessão. O middleware pode embutir todos os reportes de medição DASH em um reporte de recepção comum, que pode incluir a especificação de identificadores para os clientes DASH respectivos (por exemplo, em um campo clientID no reporte de medição DASH).

[0138] A figura 13 é um fluxograma ilustrando um método ilustrativo de acordo com as técnicas dessa descrição. As etapas do método ilustrativo da figura 13 são descritas como sendo realizadas pela unidade de middleware 200 e cliente DASH 212 na figura 5, respectivamente. Deve- se compreender que esse ou um método similar a esse pode ser realizado por outros conjuntos de clientes DASH e middleware, tal como, por exemplo, MSDC 112', 112" e cliente DASH 108', 108" das figuras 2 e 3.

[0139] Inicialmente, a unidade de middleware 200 recebe uma ADPD incluindo um elemento de reporte DASH (350). Como discutido acima, o elemento de reporte DASH pode incluir um ou mais de um indicador indicando se as métricas DASH devem ser reportadas, as métricas DASH a serem reportadas, se o reporte de métrica DASH deve ser sincronizado com os reportes de recepção MBMS e/ou um percentual de amostragem de QoE DASH se o reporte de métrica DASH não for sincronizado com os reportes de recepção MBMS.

[0140] Assumindo-se que ADPD indique que as métricas DASH devem ser incluídas nos reportes de recepção MBMS, a unidade de middleware 200 pode atualizar um arquivo de manifesto, tal como MPD DASH, para identificar a unidade de middleware 200 como o alvo para o reporte de métricas DASH (352). Por exemplo, a unidade de middleware 200 pode especificar um endereço de localhost como o endereço de um servidor de reporte de recepção de métricas DASH no arquivo de manifesto. A unidade de middleware 200 pode enviar adicionalmente o arquivo de manifesto, por exemplo, a MPD DASH, para o cliente DASH 212 (354). O cliente DASH 212 também pode receber a MPD da unidade de middleware 200 (356).

[0141] Subsequentemente, a unidade de middleware 200 pode receber dados de mídia (358), por exemplo, de acordo com uma difusão ou multidifusão MBMS ou eMBMS. A unidade de middleware 200 pode armazenar temporariamente os dados de mídia recebidos (360), por exemplo, na memória cache 204. O cliente DASH 212 pode, então, solicitar todos ou uma parte dos dados de mídia recebidos da unidade de middleware 200 (362). Em resposta à solicitação, a unidade de middleware 200 pode enviar os dados de mídia solicitados para o cliente DASH 212 (364).

[0142] O cliente DASH 212 pode, então, receber os dados de mídia (366). O cliente DASH 212 pode reportar também as métricas DASH para recepção de dados de mídia para a unidade de middleware 200 (368), por exemplo, de acordo com o arquivo de manifesto recebido da unidade de middleware 200. Apesar de não ilustrado na figura 13, deve- se compreender que o cliente DASH 212 também pode processar os dados de mídia recebidos, por exemplo, pela distribuição dos dados de mídia recebidos para o aplicativo de mídia 214.

[0143] A unidade de middleware 200 pode receber o reporte de métricas DASH do cliente DASH 212 (370). Por exemplo, a unidade de middleware 200 pode receber uma submissão de HTTP POST incluindo as métricas DASH do cliente DASH 212. No exemplo da figura 13, a unidade de middleware 200 gera um reporte de recepção MBMS incluindo as métricas DASH (372). Dessa forma, a unidade de middleware 200 pode gerar um reporte de recepção cobrindo a recepção de dados de mídia de acordo com as diretivas de reporte de uma ADPD recebidas de um dispositivo servidor, que também inclui os reportes de QoE DASH recebidos do cliente DASH 212. No entanto, em outros exemplos, a unidade de middleware 200 pode distribuir o reporte de recepção MBMS e reportes de QoE DASH separadamente e, em alguns casos, para servidores de reporte separados. No exemplo da figura 13, no entanto, a unidade de middleware 200 envia o reporte de recepção, incluindo as métricas DASH recebidas do cliente DASH 212, para um servidor de mídia do qual os dados de mídia foram recebidos (374).

[0144] Em um exemplo, a unidade de middleware 200 designa diferentes tipos MIME de múltiplas partes para o reporte de recepção MBMS e as métricas DASH, para diferenciar entre esses dois reportes. Isso é, a unidade de middleware 200 pode designar um primeiro valor de tipo MIME de múltiplas partes para o reporte de recepção MBMS e um segundo valor de tipo MIME de múltiplas partes diferente para as métricas DASH. Dessa forma, o servidor de reporte de recepção para o qual a unidade de middleware 200 distribui os reportes de recepção pode diferenciar o reporte de recepção MBMS das métricas DASH utilizando os tipos MIME de múltiplas partes.

[0145] Dessa forma, o método da figura 13 representa um exemplo de um método, realizado por uma unidade de middleware de um dispositivo de cliente, incluindo o recebimento de dados de mídia através da difusão ou multidifusão de um dispositivo servidor, gerando reportes de recepção que cobrem a recepção dos dados de mídia de acordo com as diretivas de reporte recebidas, distribuindo pelo menos parte dos dados de mídia para um aplicativo alvo do dispositivo de cliente, recebendo reportes de qualidade de experiência (QoE) do aplicativo alvo, e fornecendo conteúdo dos reportes de QoE para um servidor de reporte de recepção. Novamente, nesse exemplo, os reportes de recepção incluem o conteúdo dos reportes de QoE, mas em outros exemplos, esses reportes podem ser distribuídos separadamente e/ou para servidores de reporte separados.

[0146] A figura 14 é um fluxograma ilustrando outro método ilustrativo de acordo com as técnicas dessa descrição. O método da figura 14 é descrito com relação à unidade de middleware 200, apesar de dever ser compreendido que outros dispositivos, tal como MSDC 112', 112" das figuras 2 e 3, poderem ser configurados para realizar esse ou um método similar.

[0147] Inicialmente nesse exemplo, a unidade de middleware 200 recebe dados de mídia através de difusão ou multidifusão (380), por exemplo, de acordo com MBMS ou eMBMS. Apesar de não ilustrado na figura 14, deve-se compreender que antes do recebimento dos dados de mídia, a unidade de middleware 200 pode assinar um serviço MBMS ou eMBMS particular. Adicionalmente, a unidade de middleware 200 pode receber uma ADPD incluindo diretivas de reporte, tal como quando gerar reportes de recepção, que informação incluir nos reportes de recepção e similares. Ademais, ADPD pode, de acordo com as técnicas dessa descrição, incluir dados indicando se os reportes de QoE DASH devem ser incluídos nos reportes de recepção ou submetidos separadamente, e se os reportes de QoE DASH forem submetidos separadamente, um endereço de rede de um servidor de reporte de métrica de QoE DASH.

[0148] A unidade de middleware 200 então, nesse exemplo, gera um reporte de recepção cobrindo a recepção de dados de mídia de acordo com as diretivas de reporte recebidas (382) de ADPD. Em geral, os reportes de recepção são enviados depois de um tempo de backoff e um período de randomização. Esse retardo garantirá que o middleware possa receber os reportes de medição de QoE DASH gerados pelo cliente DASH. Em qualquer caso, deve-se compreender que a postagem do reporte de recepção não precisa ser realizada imediatamente após o recebimento dos dados de mídia, mas pode, em vez disso, ser atrasada, se necessário, até depois do recebimento do reporte de métricas de QoE DASH, como discutido abaixo.

[0149] A unidade de middleware 200 também distribui dados de mídia para um aplicativo alvo (384), por exemplo, um cliente DASH, tal como o cliente DASH 212 da figura 5. Em particular, a unidade de middleware 200 pode armazenar temporariamente os dados de mídia recebidos, por exemplo, na memória cache 204, e esperar por uma solicitação para os dados de mídia, ou partes dos mesmos, por parte do cliente DASH 212. A unidade de middleware 200 pode enviar os dados de mídia solicitados para um cliente DASH 212 em resposta a tais solicitações. As solicitações podem compreender solicitações HTTP GET ou GET parcial (isso é, solicitações GET que especificam faixas de byte de um URL alvo). Adicionalmente, antes da distribuição de dados de mídia para o cliente DASH 212, a unidade de middleware 200 pode enviar um arquivo de manifesto, tal como MPD, para o cliente DASH 212. O arquivo de manifesto pode indicar que os reportes de métrica de QoE DASH sejam distribuídos para a unidade de middleware 200, além de outra informação de arquivo de manifesto, tal como URLs dos arquivos de mídia, horário de relógio indicando quando os arquivos de mídia estarão disponíveis, e similares. Ademais, a unidade de middleware 200 pode modificar o arquivo de manifesto para identificar a unidade de middleware 200 como o servidor para o qual o cliente DASH 212 deve enviar os reportes de métricas de QoE DASH.

[0150] Nesse exemplo, depois da distribuição de dados de mídia para o aplicativo alvo, a unidade de middleware 200 recebe um reporte de QoE do aplicativo alvo (386). Por exemplo, a unidade de middleware 200 pode receber o reporte de QoE DASH do cliente DASH 212. O reporte de QoE DASH pode incluir dados representando valores para várias métricas DASH solicitadas, tal como o rendimento médio, o retardo de transmissão inicial e informação MPD em adição a uma lista de transações de Solicitação/Resposta HTTP, uma lista de eventos de mudança de representação, um nível de armazenamento, uma lista de conexões TCP, uma lista de eventos de mudança de representação, um nível de armazenamento e/ou uma lista de reprodução.

[0151] A unidade de middleware 200 pode, então, fornecer o conteúdo do reporte de QoE DASH para o servidor de reporte de recepção (388), por exemplo, como indicado por ADPD. Em um exemplo, a unidade de middleware 200 pode distribuir o reporte de recepção MBMS ou eMBMS e o conteúdo do reporte de QoE DASH separadamente. Em outros exemplos, a unidade de middleware 200 pode distribuir o reporte de recepção MBMS/eMBMS e o conteúdo do reporte de QoE DASH em conjunto, por exemplo, em um documento singular (por exemplo, um arquivo singular ou outro conjunto de dados). Em alguns exemplos, quando esses reportes são distribuídos juntos, a unidade de middleware 200 pode identificar os reportes utilizando tipos MIME de múltiplas partes distintos, por exemplo, um primeiro tipo MIME de múltiplas partes para o reporte de recepção MBMS e um segundo tipo MIME de múltiplas partes diferente, para o reporte de QoE DASH.

[0152] Dessa forma, o método da figura 14 representa um exemplo de um método, realizado por uma unidade de middleware de um dispositivo de cliente, incluindo o recebimento de dados de mídia através de difusão ou multidifusão de um dispositivo servidor, gerando reportes de recepção cobrindo a recepção de dados de mídia de acordo com as diretivas de reporte recebidas, distribuindo pelo menos parte dos dados de mídia para um aplicativo alvo do dispositivo de cliente, recebendo reportes de qualidade de experiência (QoE) do aplicativo alvo, e fornecendo conteúdo dos reportes de QoE para um servidor de reporte de recepção. Novamente, nesse exemplo, os reportes de recepção incluem o conteúdo dos reportes de QoE, mas em outros exemplos, esses reportes podem ser distribuídos separadamente e/ou para servidores de reporte separados. Alternativamente, a unidade de middleware 200 pode utilizar cabeçalhos XML distintos para distinguir o reporte de recepção MBMS do reporte de QoE DASH.

[0153] A figura 15 é um diagrama em bloco ilustrando exemplos de um dispositivo servidor 400 e um dispositivo de cliente 410 configurados de acordo com as técnicas dessa descrição. O dispositivo servidor 400 pode corresponder ao servidor de provisionamento e BMSC 104 das figuras 2 e 3, o dispositivo servidor 160 e/ou o dispositivo de preparação de conteúdo 140 da figura 4. O dispositivo de cliente 410 pode corresponder ao UE 106 das figuras 2 ou 3 e/ou dispositivo de cliente 180 da figura 4. Dessa forma, o dispositivo de cliente 410 representa um exemplo do equipamento de usuário (UE), tal como o computador pessoal, dispositivo móvel tal como telefone celular, tablet, ou laptop, caixa de decodificação ou similar.

[0154] Nesse exemplo, o dispositivo de cliente 410 inclui o cliente DASH 412 e a unidade de middleware 414. O cliente DASH 412 pode corresponder ao cliente DASH 108' da figura 2, ao cliente DASH 108" da figura 3 ou ao cliente DASH 212 da unidade de recuperação 192 na figura 5. A unidade de middleware 414 pode corresponder a MSDC 112' da figura 2, MSDC 112" da figura 3, ou middleware eMBMS 200 da unidade de recuperação 192 na figura 5. O cliente DASH 412 pode representar, por exemplo, um plug-in com base em software para um navegador de rede executado pelo dispositivo de cliente 410.

[0155] A unidade de middleware 414 e o cliente DASH 412 podem ser implementados em hardware, software, firmware ou uma combinação dos mesmos. Quando implementado em software ou firmware, é esperado que o hardware requerido, tal como mídia legível por computador e uma ou mais unidades de processamento, também seja fornecido. Em geral, as unidades de processamento são implementadas utilizando-se um conjunto de circuitos lógicos digital fixo ou programável, tal como um ou mais dentre ASICs, DSPs, FPGAs, microprocessadores ou similares.

[0156] De acordo com as técnicas dessa descrição, a unidade de middleware 414 pode ser configurada para receber dados de mídia através de difusão ou multidifusão do dispositivo servidor 400, gerar reportes de recepção cobrindo a recepção de dados de mídia de acordo com as diretivas de reporte recebidas, distribuir pelo menos parte dos dados de mídia para o cliente DASH 412 (representando um exemplo de um aplicativo alvo, nesse exemplo) do dispositivo de cliente 410, receber reportes de qualidade de experiência (QoE) do cliente DASH 412, e fornecer conteúdo dos reportes de QoE para um servidor de reporte de recepção. O servidor de reporte de recepção pode corresponder ao dispositivo servidor 400, ou um dispositivo servidor separado (não ilustrado).

[0157] Em um ou mais exemplos, as funções descritas podem ser implementadas em hardware, software, firmware ou qualquer combinação dos mesmos. Se implementadas em software, as funções podem ser armazenadas em ou transmitidas como uma ou mais instruções ou código em um meio legível por computador e executadas por uma unidade de processamento com base em hardware. O 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 o outro, por exemplo, de acordo com um protocolo de comunicação. Dessa forma, o meio legível por computador pode geralmente 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. O meio de armazenamento de dados pode ser qualquer meio disponível que possa ser acessado por um ou mais computadores ou um ou mais processadores parra a recuperação de instruções, código e/ou estruturas de dados para implementação das técnicas descritas nessa descrição. Um produto de programa de computador pode incluir um meio legível por computador.

[0158] Por meio de exemplo, e não de limitação, tal meio de armazenamento legível por computador pode compreender RAM, ROM, EEPROM, CD-ROM ou outro armazenamento em disco ótico, armazenamento em disco magnético, ou outros dispositivos de armazenamento magnético, memória flash ou qualquer outro meio que possa ser utilizado para armazenar o código de programa desejado na forma de instruções ou estruturas de dados e que possa ser acessado por um computador. Além disso, qualquer conexão é adequadamente chamada de meio legível por computador. Por exemplo, se instruções forem transmitidas a partir de um sítio da rede, servidor ou outra fonte remota utilizando um cabo coaxial, um cabo de fibra ótica, um par torcido, uma linha de assinante digital (DSL), ou tecnologias sem fio tal como infravermelho, rádio e micro-ondas, então o cabo coaxial, o cabo de fibra ótica, o par torcido, DSL ou tecnologias sem fio tal como infravermelho, rádio e micro-ondas são incluídos na definição de meio. Deve-se compreender, no entanto, que meio de armazenamento legível por computador e meio ode armazenamento de dados não incluem conexões, ondas portadoras, sinais, ou outra mídia transitória, as, em vez disso, são direcionados para mídia de armazenamento tangível, não transitória. Disquete e disco, como utilizados aqui, incluem disco compacto (CD), disco a laser, disco ótico, disco versátil digital (DVD), disquete, e disco Blu-ray, onde disquetes normalmente reproduzem os dados magneticamente, enquanto discos reproduzem os dados oticamente com lasers. As combinações do acima exposto também devem ser incluídas no escopo de meio legível por computador.

[0159] Instruções podem ser executadas por um ou mais processadores, tal como um ou mais processadores de sinal digital (DSPs), microprocessadores de finalidade geral, circuitos integrados específicos de aplicativo (ASICs), conjuntos de lógica programável em campo (FPGAs), ou outro conjunto de circuito lógico integrado ou discreto equivalente. De acordo, o termo "processador", como utilizado aqui, pode se referir a qualquer estrutura acima ou qualquer outra estrutura adequada para a implementação das técnicas descritas aqui. Adicionalmente, em alguns aspectos, a funcionalidade descrita aqui pode ser fornecida dentro de hardware dedicado e/ou módulos de software configurados para codificar e decodificar, ou incorporada em um codec combinado. Além disso, as técnicas podem ser totalmente implementadas em um ou mais circuitos ou elementos lógicos.

[0160] As técnicas dessa descriçã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 conjunto de chips). Vários componentes, módulos, ou unidades são descritos nessa descrição para enfatizar os aspectos funcionais dos dispositivos configurados para realizar as técnicas descritas, mas não exigem necessariamente a realização por unidades de hardware diferentes. Em vez disso, como descrito acima, várias unidades podem ser combinadas em uma unidade de hardware codec ou fornecidas por uma coleção de unidades de hardware interoperacionais, incluindo um ou mais processadores como descrito acima, em conjunto com software e/ou firmware adequado.

[0161] Vários exemplos foram descritos. Esses e outros exemplos estão dentro do escopo das reivindicações a seguir.

Claims (15)

1. Método de geração de reportes de medição de qualidade de experiência, QoE, DASH, caracterizado pelo fato de que compreende, por uma unidade de middleware de um dispositivo de cliente MBMS: receber (380) dados de mídia através de difusão ou multidifusão a partir de um dispositivo servidor; gerar (382) reportes de recepção MBMS cobrindo a recepção dos dados de mídia de acordo com as diretivas de reporte recebidas; distribuir (384) pelo menos parte dos dados de mídia para um aplicativo alvo do dispositivo de cliente DASH; receber (386) reportes QoE DASH incluindo métricas de QoE a partir do aplicativo alvo; e fornecer (388) conteúdo dos reportes de recepção MBMS e reportes QoE DASH para um servidor de reporte de recepção.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o servidor de reporte de recepção é o mesmo que o dispositivo servidor.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente sinalizar, para o aplicativo alvo, um endereço de localhost do dispositivo de cliente como um endereço de destino ao qual o aplicativo alvo deve enviar as métricas de QoE.

4. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que receber as métricas de QoE compreende receber uma submissão de HTTP POST do reporte de Medição de QoE para o endereço localhost especificado a partir do aplicativo alvo.

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente enviar, para o aplicativo alvo, um arquivo de manifesto para os dados de mídia que inclui dados indicando as métricas de QoE a serem reportadas.

6. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que compreende adicionalmente modificar uma versão original do arquivo de manifesto para os dados de mídia para incluir os dados indicando as métricas de QoE a serem fornecidas para o dispositivo servidor.

7. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que compreende adicionalmente receber os dados indicando as métricas de QoE a serem fornecidas para o dispositivo servidor a partir do dispositivo servidor.

8. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que o arquivo de manifesto inclui uma pluralidade de elementos de métrica, cada um dentre a pluralidade de elementos de métrica incluindo as métricas de atributo respectivas a serem fornecidas para o dispositivo servidor.

9. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente receber dados indicando que as métricas de QoE devem ser reportadas para o servidor de reporte de recepção.

10. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que receber dados compreende adicionalmente receber dados indicando pelo menos uma dentre: se as métricas de QoE devem ser comprimidas, a lista de métricas de QoE a serem reportadas, se o reporte de métricas de QoE deve ser sincronizado com o reporte de recepção para a difusão ou multidifusão, ou um percentual de amostragem de QoE DASH representativo de uma probabilidade condicional para a qual as métricas de QoE devem ser reportadas.

11. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que receber os dados compreende receber os dados em uma descrição de procedimento de distribuição associada, ADPD.

12. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que fornecer as métricas de QoE compreende enviar um documento singular para o dispositivo servidor, o documento singular incluindo as métricas de QoE e os dados de reporte de recepção, e em que enviar o documento singular compreende: configurar um primeiro valor para um tipo MIME de múltiplas partes das métricas de QoE no documento singular; e configurar um segundo valor diferente para o tipo MIME de múltiplas partes dos dados de reporte de recepção no documento singular, ou em que fornecer as métricas de QoE compreende enviar um documento singular para o dispositivo servidor, o documento singular incluindo as métricas de QoE e os dados de reporte de recepção, e em que enviar o documento singular compreende: configurar um primeiro cabeçalho de linguagem extensível de marcação, XML, das métricas de QoE no documento singular; e configurar um segundo cabeçalho XML diferente dos dados de reporte de recepção no documento singular, ou em que o aplicativo alvo compreende um primeiro aplicativo alvo, em que receber as métricas de QoE compreende receber um primeiro conjunto de métricas de QoE a partir do primeiro aplicativo alvo, o método compreendendo adicionalmente: receber uma pluralidade de métricas de QoE, incluindo o primeiro conjunto de métricas de QoE, a partir de uma pluralidade de aplicativos alvo, incluindo o primeiro aplicativo alvo, em que fornecer as métricas de QoE compreende enviar um reporte incluindo a pluralidade de métricas de QoE para o servidor de reporte de recepção.

13. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: enviar instruções para o aplicativo alvo para reportar as métricas de QoE para todos os dados recebidos; e descartar pelo menos alguns dos reportes com base em uma probabilidade de coleta.

14. Dispositivo de cliente para gerar reportes de medição de qualidade, caracterizado pelo fato de que compreende:meios dispostos a realizar o método conforme definido em qualquer uma das reivindicações 1 a 13.

15. Memória legível por computador caracterizada pelo fato de que compreende instruções armazenadas na mesma, as instruções sendo executáveis por um computador para realizar o método conforme definido em qualquer uma das reivindicações 1 a 13.