UNIVERSIDADE PRESBITERIANA MACKENZIE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA E COMPUTAÇÃO RODRIGO ADMIR VAZ AVALIAÇÃO DA LATÊNCIA E ESCALABILIDADE DE VÍDEO POR BROADBAND E BROADCAST UTILIZANDO-SE O SISTEMA ATSC 3.0 São Paulo 2024 Rodrigo Admir Vaz AVALIAÇÃO DA LATÊNCIA E ESCALABILIDADE DE VÍDEO POR BROADBAND E BROADCAST UTILIZANDO-SE O SISTEMA ATSC 3.0 Tese de Doutorado apresentada ao Programa de Pós-Graduação em Engenharia Elétrica e Com- putação da Universidade Presbiteriana Macken- zie, como requisito para a obtenção do título de Doutor em Engenharia Elétrica. Orientador: Professor Doutor Cristiano Akamine São Paulo 2024 V393t Vaz, Rodrigo Admir Avaliação de latência e escalabilidade de vídeo por broadband e broadcast utilizando-se o sistema atsc 3.0: [recurso eletrônico] / Rodrigo Admir Vaz 3600KB ; il. Tese (Doutorado em Engenharia Elétrica e Computação) - Universidade Presbiteriana Mackenzie - São Paulo, 2024. Orientador: Cristiano Akamine. Referências Bibliográficas: f. 1-159. 1. TV 3.0 2. Vídeo Escalável. 3. ROUTE/DASH 4. Transmissão Híbrida 5. TV digital I. Vaz, Rodrigo Admir, orientador II. Akamine, Cristiano, III.Título. Bibliotecário(a) Responsável: Maria Gabriela Brandi Teixeira - CRB 8/6339 FOLHA DE IDENTIFICAÇÃO DE AGÊNCIA DE FOMENTO Autor: Rodrigo Admir Vaz Programa de Pós Graduação Stricto Sensu em Engenharia Elétrica e Com- putação Título do Trabalho: AVALIAÇÃO DA LATÊNCIA E ESCALABILIDADE DE VÍDEO POR BROADBAND E BROADCAST UTILIZANDO-SE O SIS- TEMA ATSC 3.0 O Presente trabalho foi realizado com o apoio de: [ ] CAPES: Coordenação de Aperfeiçoamento de Pessoal de Nível Superior [ ] CNPq: Conselho Nacional de Desenvolvimento Científico e Tecnológico [ ]FAPESP: Fundação de Amparo à Pesquisa do Estado de São Paulo [ ]Instituto Presbiteriano Mackenzie/Isenção Integral de Mensalidades e Taxas [ ] MACKPESQUISA - Fundo Mackenzie de Pesquisa [x] Empresa/Indústria: SIDIA/Samsung [ ] Outro Dedico este trabalho ao Criador que mais do que nunca ajudou-me nesta jornada, ensinando- me Suas filosofias e como, cada vez mais, confiar nos Seus caminhos e mistérios. Aos meus pais, irmão, esposa e filhos, que me ajudaram ao longo desta vida, através de sua educação e conhecimentos repassados ao longo dos anos, em como ser um ser uma pessoa me- lhor. Além dos meus amigos que me ajudaram na elaboração, concepção e revisão deste trabalho. Temet Nosce (Sócrates – Filósofo Grego) Neo, you’re going realize, just as I did that there’s a difference between knowing the path and walking the path (Morpheus - The Matrix) Conhecereis a verdade e a verdade vos liber- tará! (Jo 8,32) i AGRADECIMENTOS • Agradeço ao nosso Senhor pela oportunidade, incentivo, sinais, paciência e apren- dizado dedicados a mim nesta oportunidade de estudo; • Agradeço aos SIDIA/Samsung pela compreensão, oportunidade, financiamento e ajuda através do programa educacional para elaboração desta Tese de Doutorado; • Agradeço ao meu orientador, Professor Doutor Cristiano Akamine pela oportuni- dade, paciência, vivência e orientação para realização deste trabalho; • Agradeço à Universidade Presbiteriana Mackenzie pela oportunidade e pelas instru- ções e ambiente de trabalho providos para o desenvolvimento deste trabalho; • Agradeço a todos aqueles que me ajudaram na elaboração deste trabalho e que de alguma forma contribuíram para sua elaboração e realização, de forma especial, gostaria de agradecer os também pós-graduandos: Allan Chaubet, Fadi Jerji, George Maranhão, Natália Santiago, Ricardo Rabaça e a todos aqueles que fizeram suas contribuições para a elaboração desta tese; • De forma especial, gostaria de agradecer aos pós-graduandos George Maranhão, res- ponsável pela implementação, configuração e testes no set up experimental, Allan Chau- bet pelo suporte na montagem do ambiente experimental e Fadi Jerji por confeccionar e ensinar-me como utilizar o emulador de redes UDP; • Agradeço aos meus pais, irmão, à minha esposa e ao meu filho pela paciência, edu- cação, incentivo e apoio nesta empreitada. • Agradeço aos Professores Doutores Edson Hirata e Célia Siqueira, além das tera- peutas Mara Fernandes e Jussara Cruz de Souza e Lebisch pelo incentivo e apoio em perseverar e continuar me dedicando às pesquisas; • Agradeço ainda à Elecard, na figura da senhora Olga Gamolina e do engenheiro Alexander Kruglov pelos esclarecimentos para a realização das medidas de qualidade ob- jetiva de vídeo. ii RESUMO O surgimento das modernas tecnologias de comunicação e informação multimídia vem impactando e transformando a vida da sociedade atual, alterando hábitos e costumes de seus usuários. A visualização destes efeitos não tem sido diferente no universo da TV (Television - Televisão) Digital. A sua inovadora proposta de entrega de conteúdos de vídeo ao usuário através de diferentes recursos, como a Internet, promete revolucionar hábitos e costumes dos usuários. A utilização do recurso de vídeo escalável volta à cena, de acordo com a publicação das modernos padrões de codificação de vídeo e de acordo com os recentes sistemas de TV digital, como o sistema ATSC (Advanced Television System Committee - Comitê de Sistema de Televisão Avançada) 3.0. Esta tese tem por objetivo a avaliação das características de escalabilidade de vídeo do padrão de codificação MPEG (Motion Picture Experts Group - Grupo de Especialistas em Quadros de Movimento) H - Parte 2/H.265 SHVC (Scalable High Video Coding - Codificação de Alta Eficiência de Vídeo Escalável), transmitindo suas camadas de forma híbrida: a camada base por RF (Radio Frequency - Radiofrequência) e a camada de enriquecimento pela Internet para utilização no próximo padrão de sistema de TV digital terrestre brasileiro. Para tal, é feita uma revisão da literatura dos padrões de codificação de vídeo existentes e em desenvolvimento, assim como dos diferentes padrões de multiplexação de A/V (Audio and Video - Áudio e Vídeo) atuais e em desenvolvimento. O ambiente experimental reproduz a cadeia de transmissão e recepção de TV digital terrestre, através do sistema ATSC 3.0, onde são feitos os procedimentos experimentais para transmissão híbrida do conteúdo de vídeo escalável. Desta maneira é feita uma avaliação a respeito da mudança da resolução espacial na transmissão e recepção, onde alcançou-se o êxito na recepção híbrida do conteúdo de vídeo fazendo o enriquecimento do vídeo de resolução FHD (Full High Definition - Alta Definição Completa) 2K para resolução UHD (Ulta High Definition - Definição Ultra Alta) 4K. Através da recepção híbrida, avaliou-se a latência de recepção entre os conteúdos recebidos por RF e pela Internet, medindo-se um valor médio máximo menor que 1500 ms, permitindo-se recomendar um buffer temporal mínimo de 2000 ms aos receptores da nova geração de TV digital com suporte ao vídeo escalável e à recepção híbrida para enfrentar as instabilidades da rede e oferecer uma boa experiência de uso ao usuário final. Palavras-chave: Vídeo Escalável, TV Digital, ATSC 3.0, TV 3.0, Internet, Transmissão Híbrida, ROUTE/DASH. iii ABSTRACT The emergence of modern communication and multimedia information technologies have been impacting and transforming the life of today’s society, changing the habits and customs of its users. The visualization of these effects has not been different in the digital TV (Television) universe. Its innovative proposal to deliver video content to the user through different resources, such as the Internet, promises to revolutionize the habits and customs of users. The use of the scalable video resource returns to the scene, according to the publication of modern video encoding standards and according to the recent digital TV systems, such as the ATSC (Advanced Television System Committee) 3.0 system. This thesis aims to evaluate the video scalability features of the MPEG (Motion Picture Experts Group) H encoding standard - Part 2 / H.265 SHVC (Scalable High Video Coding), making hybrid transmission of its layers: the base layer via RF (Radio Frequency) and the enhacment layer over the Internet to be used in the next standard of Brazilian terrestrial digital TV system. Therefore, a review of the existing and under development video coding standards literature is made, as well as the different current and under development A/V (Audio and Video) multiplexing standards. The experimental environment reproduces the transmission and reception chain of digital terrestrial TV, through the ATSC 3.0 system, where experimental procedures are carried out for scalable video content hybrid transmission. Therefore, an evaluation is made about in spatial resolution change in transmission and reception, where successful hybrid video content reception was achieved by enhancing the FHD (Full High Definition) 2K video resolution to UHD (Ulta High Definition) 4K resolution. Using hybrid reception, it was evaluated the reception latency between the video content received via RF and the Internet, measuring a maximun avarage value smaller than 1500 ms, allowing to recommend a minimum temporal buffer of 2000 ms for the new digital TV generation receivers with video support to scalable video and hybrid reception to face network instabilities and offer a good user experience to the final user. Keywords: Scalable Vdeo, Digital TV, ATSC 3.0, TV 3.0, Internet, Hybrid Transmission, ROUTE/DASH. iv LISTA DE FIGURAS 1 Tecnologias Adotadas pela TV 3.0 ao final do Ano de 2021. . . . . . . . . . 7 2 Crescimento do Número de Assinaturas de Internet Banda Larga no Brasil - Tecnologia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3 Crescimento do Número de Assinaturas de Internet Banda Larga no Brasil - Velocidade de Conexão. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4 Histórico dos Padrões de Codificação de Vídeo. . . . . . . . . . . . . . . . 16 5 Conceito Geral de Codificação Escalável. . . . . . . . . . . . . . . . . . . . 17 6 Escalabilidade Espacial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7 Escalabilidade Temporal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8 Escalabilidade de Qualidade de Imagem. . . . . . . . . . . . . . . . . . . . 21 9 Estrutura de um GOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 10 Estrutura Hierárquica dos Elementos do Vídeo MPEG-1. . . . . . . . . . . 26 11 Comparação da Qualidade de Imagem Subjetiva MOS. . . . . . . . . . . . 42 12 Estrutura Lógica de um Pacote MMT. . . . . . . . . . . . . . . . . . . . . 62 13 Pilha Receptora Unificada Radiodifusão e Banda Larga. . . . . . . . . . . 66 14 Pilha de protocolos do sistema ATSC 3.0. . . . . . . . . . . . . . . . . . . 71 15 Diagrama de Interconexão Física dos Equipamentos. . . . . . . . . . . . . 77 16 Diagrama Lógico de Conexão dos Equipamentos. . . . . . . . . . . . . . . 78 17 Serviços 6002 no Multiplexador. . . . . . . . . . . . . . . . . . . . . . . . . 84 18 Configuração dos PLPs no Scheduler. . . . . . . . . . . . . . . . . . . . . . 84 19 Análise do Sinal ATSC 3.0 via IMAS. . . . . . . . . . . . . . . . . . . . . . 85 20 BL - Resolução Espacial (720x480). . . . . . . . . . . . . . . . . . . . . . . 86 21 BL + EL - Resolução Espacial (1280x720). . . . . . . . . . . . . . . . . . . 86 22 BL - Resolução Espacial (1920x1080). . . . . . . . . . . . . . . . . . . . . . 87 23 BL + EL - Resolução Espacial (3840x2160). . . . . . . . . . . . . . . . . . 88 24 Diagrama de Blocos de Transmissão dos BL e EL por Meios Distintos. . . 89 25 Arquivo Manifest Original . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 26 Arquivo Manifest Modificado . . . . . . . . . . . . . . . . . . . . . . . . . 92 27 Análise de um Pacote ROUTE/DASH. . . . . . . . . . . . . . . . . . . . . 94 28 Estrutura do Arquivo Manifest.MPD Proposto. . . . . . . . . . . . . . . . 97 v 29 Exemplo de Escrita do Arquivo Manifest.MPD Proposto. . . . . . . . . . . 98 30 Proposta de Arquitetura do Receptor . . . . . . . . . . . . . . . . . . . . . 99 31 Gráfico de Latência Entre o BL e o EL. . . . . . . . . . . . . . . . . . . . . 101 32 Vídeo enriquecido para UHD 4K pelo Receptor de DTV . . . . . . . . . . 103 33 BL (FHD 2K) do vídeo ISDB-Tb (UHD 4K). . . . . . . . . . . . . . . . . 115 34 BL + EL (UHD 4K) do vídeo ISDB-Tb (UHD 4K). . . . . . . . . . . . . . 115 35 BL (FHD 2K) do vídeo original (UHD 4K). . . . . . . . . . . . . . . . . . 116 36 BL + EL (UHD 4K) do vídeo original (UHD 4K). . . . . . . . . . . . . . . 117 37 DigiCAP - PCAP Stream Generator. . . . . . . . . . . . . . . . . . . . . . 129 38 Codificador de Vídeo ATEME Titan. . . . . . . . . . . . . . . . . . . . . . 130 39 DigiCAP - Digicaster Multiplexer. . . . . . . . . . . . . . . . . . . . . . . . 131 40 DigiCAP - Digicaster Scheduler. . . . . . . . . . . . . . . . . . . . . . . . . 131 41 Pro Television - Modulator. . . . . . . . . . . . . . . . . . . . . . . . . . . 132 42 Agos - IMAS (Integrated Measurement Analysis Software). . . . . . . . . . 133 43 Recepção do Vídeo Escalável Através da Ferramenta GPAC - BL (FHD) 2K - bitrate 2 Mbps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 44 Recepção do Vídeo Escalável Através da Ferramenta GPAC - BL+EL (UHD) 4K - bitrate 4.5 Mbps. . . . . . . . . . . . . . . . . . . . . . . . . . 134 45 Extrator dos Segmentos de Vídeo Concebido em C++. . . . . . . . . . . . 134 46 Kai Media - ATSC 3.0 Multi Player (Analyzer). . . . . . . . . . . . . . . . 135 vi LISTA DE TABELAS 1 Comparação do Desempenho de Vídeo para a Mesma Qualidade Subjetiva Redução média de bitrate comparada com padrão H.264 AVC HP . . . . . 33 2 Comparação dos Recursos de Escalabilidade Suportados pelos Padrões SVC e SHVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3 Latência Média Entre o BL e o EL . . . . . . . . . . . . . . . . . . . . . . 101 4 Avaliação da Qualidade Objetiva de Vídeo Sinal ISDB-Tb . . . . . . . . . 111 5 Avaliação da Qualidade Objetiva de Vídeo Sinal Original UHD 4K . . . . . 112 6 Percepção da Qualidade de Vídeo e Respectivas Faixas de Valores Objetivos113 Siglas A/V Audio and Video - Áudio e Vídeo ABNT Associação Brasileira de Normas Técnicas - Technical Standards Brazilian Asso- ciation ACATS Advisory Committee on Advanced Television Service - Comitê Consultivo sobre Serviço de Televisão Avançada ACC Advanced Coefficient Coding - Codificação Avançada de Coeficientes ACPR Advanced Core Profile - Perfil Cerne Avançado ADC Asset Delivery Characteristic - Características de Entrega de Ativo ADCP Advanced Coding Efficiency Profile - Perfil Eficiência de Codificação Avançada ADTMB Advanced Digital Terrestrial Multimedia Broadcast - Transmissão Multimídia Digital Terrestre Avançada AI Affine Interprediction - Entre Predição Afim ALF Adaptive Loop Filter - Filtro de Loop Adaptativo AMVR Adaptive Motion Vector Resolution - Resolução de Vetor de Movimento Adap- tativo ANATEL Agência Nacional de Telecomunicações - National Telecommunications Agency ANSI American National Standards Institute - Instituto de Padrões Nacional Americano ARTSP Advanced Real Time Simple Profile - Simples de Tempo Real Avançado ASP Advanced Simple Profile - Perfil Simples Avançado ASTP Advanced Scalable Texture Profile - Perfil de Textura Escalável Avançada ATM Asynchronous Transfer Mode - Modo Assíncrono de Transferência ATS Adaptive Transform Selection - Seleção de Transformada Adaptável ATSC Advanced Television System Committee - Comitê de Sistema de Televisão Avan- çada ATTC Advanced Television Test Center - Centro de Teste de Televisão Avançada AU Access Unit - Unidade de Acesso AVC Advanced Video Coding - Codificação Avançada de Vídeo AWS Amazon Web Services - Serviço de Rede da Amazon B Bidirectional-Frame - Quadro Bidirecional BCH Bose Chaudhuri Hocquenghem - Bose Chaudhuri Hocquenghem BDRate Bjontegaard Delta Rate - Avaliação Delta de Bjontegaard BEAM Bitstream Extraction and Merging - Extração e Mesclagem de Fluxo de Bits BL Base Layer - Camada Base BMFF Base Media File Format - Formato de Arquivo de Mídia Base BP Baseline Profile - Perfil de Linha Base CABAC Context-Based Arithmetic Coding - Codificação Aritmética Baseada em Con- texto CAT Conditional Access Table - Tabela de Acesso Condicional CAVLC Context-Adaptive Variable Length Codes - Códigos de Comprimento Variável Adaptável ao Contexto CBPS Coding Block-Partitioning Structure - Estrutura de Particionamento de Bloco de Codificação CBR Constant Bitrate - Taxa de Bits Constante CCI Congestion Control Information - Informação de Controle de Congestionamento CD-ROM Compact Disc Read Only Memory - Disco Compacto com Memória Apenas de Leitura CDN Content Delivery Network - Rede de Entrega de Conteúdo CfP Call for Proposals - Chamada de Propostas CGS Color Gamut Scalability - Escalabilidade de Gama de Cor CI Composition Information - Informação de Composição CP Codepoint - Ponto de Código CPR Core Profile - Perfil Cerne CScP Core Scalable Profile - Perfil de Escalabilidade Cerne CSP Core Studio Profile - Perfil Estúdio Cerne CTB Coding Tree Block - Bloco de Árvore de Codificação CTU Coding Tree Unit - Unidade de Árvore de Codificação DASH Dynamic Adaptive Streaming over HTTP - Fluxo Adaptável Dinâmico sobre HTTP DCT Discrete Cosine Transform - Transformada Discreta do Cosseno DiBEG Digital Broadcasting Experts Group - Grupo de Especialistas em Transmissão Digital ix DLM Detail Loss Metric - Métrica de Perda de Detalhes DPCM Differential Pulse-Code Modulation - Modulação por Código de Pulso Diferencial DSMVR Decoder-Side Motion Vector Refinement - Refinamento de Vetores de Movi- mento Adicionais DST Discrete Sine Transform - Transformada Discreta do Seno DTMB Digital Terrestrial Multimedia Broadcast - Transmissão Multimídia Digital Ter- restre DTS Decoding Time Stamp - Selo Temporal de Decodificação DTV Digital Television - Televisão Digital DTVNEL National Engineering Lab. for DTV - Laboratório Nacional de Engenharia para TV Digital DVB Digital Video Broadcasting - Transmissão de Vídeo Digital EL Enhancement Layer - Camada de Enriquecimento EP Extended Profile - Perfil Estendido ES Elementary Stream - Fluxo Elementar ETRI Electronics and Telecommunications Research Institute - Instituto de Pesquisa em Telecomunicações e Eletrônicos EVC Essential Video Coding - Codificação de Vídeo Essencial EWBS Emergency Warning Broadcast System - Sistema de Transmissão de Alerta de Emergência FCC Federal Communications Commission - Comissão Federal de Comunicações FFMPEG Fast Forward Moving Picture Experts Group - Grupo de Especialistas em Quadros de Movimento de Avanço Rápido FGS Fine Granular Scalability - Escalabilidade Granular Fina FGSP Fine Granular Scalability Profile - Perfil de Escalabilidade Granular Fina FHD Full High Definition - Alta Definição Completa FTYP File Type Box - Caixa de Tipo de Arquivo GDR Gradual Decoding Refresh - Atualização de Decodificação Gradual GOP Group of Pictures - Grupo de Imagens GPAC Project on Advanced Content - Projeto de Conteúdo Avançado GT Grupo de Trabalho - Working Group x HbbTV Hybrid Broadcast Broadband TV - TV de Transmissão Híbrida com Banda Larga HBMVP History-Based Motion Vector Predictor - Preditor Vetor do Movimento Base- ado em Histórico HD High Definition - Definição Alta HDMI High Definition Multimedia Interface - Interface Multimídia de Alta Definição HDR High Dynamic Range - Alta Faixa Dinâmica LCT Header Length - Comprimento do Cabeçalho LCT HDTV High Definition Television - Televisão de Alta Definição HEC Header Extension Content - Conteúdo de Extensão do Cabeçalho HEL Header Extension Length - Comprimento da Extensão do Cabeçalho HET Header Extension Content - Conteúdo da Extensão do Cabeçalho HEVC High Efficient Video Coding - Codificação de Vídeo de Alta Eficiência HFR High Frame Rate - Alta Taxa de Quadros HL High Level - Nível Alto HLG Hybrid Log-Gamma - Gamma Log Híbrida HLS High Level Syntax - Sintaxe de Nível Alto HP High Profile - Perfil Alto HPHT High Power High Tower - Potência Alta Torre Alta HT High Tier - Camada Alta HTDF Hadamard Transform-Domain Filter - Filtro no Domínio de Transformada Ha- damard HTML HyperText Markup Language - Linguagem de Marcação de Hipertexto HTTP Hypertext Transfer Protocol - Protocolo de Transferência de Hipertexto I Intra-Frame - Intra-quadro IBB Integrated Broadcast Broadband - Transmissão Integrada com Banda Larga IDR Instantaneous Decoder Refresh - Refrescamento Instantâneo do Decodificador IMAS Integrated Measurement & Analysis Software - Programa de Análise e Medição Integrados IP Internet Protocol - Protocolo de Internet ISDB-T Integrated Services Digital Broadcasting - Terrestrial - Transmissão Digital de Serviços Integrados - Terrestrial xi ISO International Organization for Standardization - Organização Internacional para Padronização ISO-IEC International Organization for Standardization/International Electrotechnical Commission - Organização Internacional para Padronização/Comissão de Eletro- técnica Internacional ISO/IEC International Organization for Standardization/International Electrotechnical Commission - Organização Internacional para Padronização/Comissão de Eletro- técnica Internacional ITU International Telecommunication Union - União Internacional de Telecomunicações ITU-R International Telecommunication Union - Radiocommunication Sector - União Internacional de Telecomunicações - Setor de Radiocomunicação ITU-T International Telecommunication Union - Standardization Sector - União Inter- nacional de Telecomunicações - Setor de Padronização JCT-VC Joint Collaborative Team on Video Coding - Equipe Colaborativa Conjunta de Codificação de Vídeo JPEG Joint Photographic Experts Group - Grupo Conjunto de Especialistas Fotográficos JPG Joint Photographic Experts Group - Grupo Conjunto de Especialistas Fotográficos JVET Joint Video Experts Team - Equipe Conjunta de Especialistas em Vídeo JVT Joint Video Team - Equipe Conjunta de Vídeo LCEVC Low Complexity Enhancement Video Coding - Codificação de Vídeo Aprimorada de Baixa Complexidade LCT Layered Coding Transport - Transporte de Codificação em Camadas LDM Layered Division Multiplexing - Multiplexação por Divisão de Camadas LDPC Low Density Parity Check - Verificação de Paridade de Baixa Densidade LL Low Level - Nível Baixo LTE Long Term Evolution - Evolução de Longo Prazo M10 Main 10 - Principal 10 M10P Main 10 Profile - Perfil Principal 10 M10SP Main 10 Still Picture - Imagem Estática Principal 10 MCPD Mean Co-Located Pixel Difference - Diferença Média de Ponto Co-localizado MDAT Media Data Box - Caixa de Dados de Mídia MIMO Multiple Input Multiple Output - Múltiplas Entradas Múltiplas Saídas xii ML Main Level - Nível Principal MM10 Multilayer Main 10 - Multicamada Principal 10 MMT MPEG Multimedia Transport - Transporte Multimídia MPEG MMTP MPEG Multimedia Transport Protocol - Protocolo de Transporte Multimídia MPEG MMVD Merge with Motion Vector Difference - Mescla com a Diferença do Vetor de Movimento MOOF Movie Fragment Box - Caixa de Fragmento de Filme MOOV Movie Header Box - Caixa de Cabeçalho de Filme MOS Mean Opinion Score - Pontuação Média de Opinião MP Main Profile - Perfil Principal MPD Media Presentation Description - Descrição de Apresentação de Mídia MPEG Motion Picture Experts Group - Grupo de Especialistas em Quadros de Movi- mento MPU Media Processing Unit - Unidade Média de Processamento MSE Mean Squared Error - Erro Médio Quadrático MSPP Main Still Picture Profile - Perfil de Imagem Estática Principal MSSIM Mean Structural Similarity Index Measure - Medida do Índice de Similaridade Estrutural Média MT Main Tier - Camada Principal MVP Multi-View Profile - Perfil de Visualização Múltipla MW Middleware - Camada Intermediária NAL Network Abstraction Layer - Camada de Abstração de Rede NHK Nippon Hoso Kyokai - Japan Broadcasting Corporation - Corporação de Radiodi- fusão do Japão NIT Network Information Table - Tabela de Informação de Rede NRT Non-Real Time - Tempo Não Real NTP Network Time Protocol - Protocolo de Tempo da Rede NTSC National Television System Committee - Comitê do Sistema de Televisão Nacional NUC Non-Uniform Constellation - Constelação Não Uniforme xiii OFDM Orthogonal Frequency Division Multiplexing - Multiplexação por Divisão de Frequência Ortogonal OTA Over The Air - Através do Ar OTT Over The Top - Acima do Topo P Predicted-Frame - Quadro Previsto PAL Phase Alternating Line - Linha Alternada de Fase PAT Program Association Table - Tabela de Associação de Programa PCAP Packet Capture - Captura de Pacotes PCR Program Clock Reference - Referência do Relógio do Programa PES Packetized Elementary Stream - Fluxo Elementar Empacotado PID Packet Identifier - Identificador de Pacote PLP Physical Layer Pipe - Tubo de Camada Física PMT Program Map Table Tabela de Mapeamento de Programa PSI Program Specific Information - Informação Específica do Programa PSNR Peak Signal-to-Noise Ratio - Relação Sinal Ruído de Pico PTS Presentation Timestamp - Selo Temporal de Apresentação PUC-RIO Pontifícia Universidade Católica do Rio de Janeiro - Pontifical Catholic Uni- versity of Rio de Janeiro QAM Quadrature Amplitude Modulation - Modulação de Amplitude em Quadratura QoS Quality of Service - Qualidade de Serviço RA Random Access - Acesso Aleatório RF Radio Frequency - Radiofrequência RNP Rede Nacional de Ensino e Pesquisa - National Education and Research Network ROUTE Real Time Object Delivery over Unidirectional Transport - Entrega de Objetos em Tempo Real sobre Transporte Unidirecional RPR Reference Picture Resampling - Re-amostragem de Imagem de Referência RSSI Received Signal Strength Indicator - Indicador de Força do Sinal Recebido RTP Real Time Protocol - Protocolo de Tempo Real RTSP Real Time Streaming Protocol - Protocolo de Transmissão em Tempo Real SBP Scalable Baseline Profile - Perfil Linha Base Escalável xiv SBTVD Sistema Brasileiro de Televisão Digital - Brazilian System of Digital Television SCBP Scalable Constrained Baseline Profile - Perfil Linha Base Restrito Escalável SCHP Scalable Constrained High Profile - Perfil Alto Restrito Escalável SD Standard Definition - Definição Padrão SDR Standard Dynamic Range - Faixa Dinâmica Padrão SECAM Système Électronique Couleur Avec Mémoire - Electronic Color System With Memory - Sistema Eletrônico de Cores com Memória SFN Single Frequency Network - Rede de Frequência Única SHIP Scalable High Intra Profile - Perfil Intra Alto Escalável SHP Scalable High Profile - Perfil Alto Escalável SHVC Scalable High Video Coding - Codificação de Alta Eficiência de Vídeo Escalável SI Switching I - I com Chaveamento SIDX Segment Index Box - Caixa de Índice de Segmento SISO Single Input Single Output - Entrada Única Saída Única SM10P Scalable Main 10 Profile - Perfil Principal 10 Escalável SMP Scalable Main Profile - Perfil Principal Escalável SMT Smart Media Transport - Transporte de Mídia Inteligente SNR Signal-to-Noise Ratio - Relação Sinal Ruído SNRP SNR Scalable Profile - Perfil Escalável em SNR SP Switching P - P com Chanveamento SP Simple Profile - Perfil Simples SpSP Spatially Scalable Profile - Perfil com Escalabilidade Espacial SSIM Structural Similarity Index Measure - Medida do Índice de Similaridade Estrutural SSP Simple Studio Profile - Perfil Estúdio Simples SSPr Simple Scalable Profile - Perfil de Escalabilidade Simples STB Set-Top Box - Caixa de Recepção de Sinal de Televisão STL Studio to Transmitter Link - Enlace do Estúdio para o Transmissor STP Scalable Texture Profile - Perfil de Textura Escalável STYP Segment Type Box - Caixa de Tipo de Segmento xv SVC Scalable Video Coding - Codificação de Vídeo Escalável SVM Support Vector Machine - Máquina de Vetores de Suporte TCP Transfer Control Protocol - Protocolo de Controle de Transferência TOI Transport Object Identifier - Identificador de Objeto de Transporte TS Transport Stream - Fluxo de Transporte TSDT Transport Stream Description Table - Tabela de Descrição de Fluxo de Transporte TSI Transport Session Identifier - Identificador de Sessão de Transporte TU Transform Unit - Unidade de Transformação TV Television - Televisão UDP User Datagram Protocol - Protocolo de Datagrama do Usuário UFF Universidade Federal Fluminense - Fluminense Federal University UFJF Universidade Federal de Juiz de Fora - Federal University of Juiz de Fora UFPB Universidade Federal da Paraíba - Federal University of Paraiba UHD Ulta High Definition - Definição Ultra Alta UHDTV Ulta High Definition Television Televisão de Definição Ultra Alta UHF Ulta High Frequency - Frequência Ultra Alta UNB Universidade de Brasília - University of Brasilia URL Uniform Resource Locator - Localizador de Recurso Padrão USP Universidade de São Paulo - University of São Paulo UTC Coordinated Universal Time - Tempo Universal Coordenado VCEG Video Coding Experts Group - Grupo de Especialistas em Codificação de Vídeo VHF Very High Frequency - Frequência Muito Alta VHS Video Home System - Sistema Doméstico de Vídeo VIF Visual Information Fidelity - Fidelidade de Informação Visual VLSI Very Large Scale of Integration - Escala de Integração Muito Elevada VMAF Video Multimethod Assessment Fusion - Fusão de Avaliação Multimétodo de Vídeo VO Video Object - Objeto de Vídeo VOP Video Object Plane - Plano de Objeto de Vídeo xvi VQM Video Quality Metric - Métrica de Qualidade de Vídeo VVC Versatile Video Coding - Codificação Versátil de Vídeo WCG Wide Color Gamut - Larga Gama de Cor WEBDAV Web Distributed Authoring and Versioning - Criação e Controle de Versão Distribuído Baseado na Rede WPP Wavefront Parallel Processing - Processamento Paralelo de Frente de Onda xDSL Digital Subscriber Line - Linha Digital de Assinante XML Extensible Markup Language - Linguagem de Marcação Extensível xvii Sumário 1 INTRODUÇÃO 1 1.1 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . 11 1.3 Metodologia Adotada nesta Tese . . . . . . . . . . . . . . . . . . . . . 12 1.4 Estrutura da Tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2 CODIFICAÇÃO DE VÍDEO 14 2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2 Escalabilidade de Vídeo . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3 Formatos de Codificação de Vídeo ITU/ISO/IEC . . . . . . . . . . 22 2.3.1 Padrão JPEG ou JPG . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3.2 Padrão MPEG-1 - Parte 2 . . . . . . . . . . . . . . . . . . . . . . . 23 2.3.3 Padrão MPEG-2 – Parte 2/ITU-T H.262 . . . . . . . . . . . . . . . 25 2.3.4 Padrão MPEG-4 - Parte 2 . . . . . . . . . . . . . . . . . . . . . . . 27 2.3.5 Padrão MPEG-4 - Parte 10/ITU-T H264 - AVC . . . . . . . . . . . 28 2.3.6 Padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC . . . . . . . . . . 32 2.3.7 MPEG-I - Parte 3/ITU-T H.266 - VVC . . . . . . . . . . . . . . . 37 2.3.8 MPEG-5 - Parte 1 - EVC . . . . . . . . . . . . . . . . . . . . . . . 42 2.3.9 MPEG-5 - Parte 2 - LCEVC . . . . . . . . . . . . . . . . . . . . . 47 2.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3 CAMADA DE TRANSPORTE 50 3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.2 Formatos Contêineres ISO/IEC . . . . . . . . . . . . . . . . . . . . . 51 3.2.1 MPEG-2 - Parte 1 - TS (Transport Stream - Fluxo de Transporte) . 51 3.2.2 MPEG-4 - Parte 12 - ISO BMFF (Base Media File Format - For- mato de Arquivo de Mídia Base) . . . . . . . . . . . . . . . . . . . 54 3.2.3 MPEG-H - Parte 1 - MMT (MPEG Multimedia Transport - Trans- porte Multimídia MPEG) . . . . . . . . . . . . . . . . . . . . . . . 57 3.3 Formatos Contêineres ATSC 3.0 . . . . . . . . . . . . . . . . . . . . . 64 3.3.1 ROUTE/DASH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4 USO DO SISTEMA ATSC 3.0 PARA MEDIÇÃO DE LATÊNCIA DE VÍDEO ENTRE BROADCAST E BROADBAND COMO CONTRI- BUIÇÃO PARA A PRÓXIMA GERAÇÃO DE TV DIGITAL TER- RESTRE BRASILEIRA 68 4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.1.1 ATSC – Advanced Television Standard Comitte . . . . . . . . . . . 69 4.1.2 Transição para o Sistema ATSC 3.0 . . . . . . . . . . . . . . . 70 4.2 Propostas e Estudos em Direção à Próxima Geração de TV Di- gital Brasileira . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.3 Ambiente Experimental . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.4 Transmissão do Conteúdo de Vídeo Escalável . . . . . . . . . . . . . 83 4.5 Recepção do Conteúdo de Vídeo Escalável . . . . . . . . . . . . . . . 85 4.6 Estudo Off-Line para Transmissão do BL e do EL por Meios Dis- tintos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.7 Analisador ROUTE/DASH . . . . . . . . . . . . . . . . . . . . . . . . 92 4.8 Extrator de Segmentos de Vídeo ISO-BMFF . . . . . . . . . . . . . 93 4.9 Proposta do Arquivo Manifesto . . . . . . . . . . . . . . . . . . . . . 97 4.10 Proposta da Arquitetura do Receptor . . . . . . . . . . . . . . . . . 98 4.11 Testes Propostos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 4.12 Resultado dos Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.13 Vantagens em Relação a Outras Implementações . . . . . . . . . . . 102 4.14 Avaliação da Qualidade de Vídeo . . . . . . . . . . . . . . . . . . . . . 104 4.15 Avaliação da Qualidade Objetiva de Vídeo . . . . . . . . . . . . . . . 106 4.15.1 Métrica de PSNR (Peak Signal-to-Noise Ratio - Relação Sinal Ruído de Pico) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 4.15.2 Métrica SSIM (Structural Similarity Index Measure - Medida do Índice de Similaridade Estrutural) . . . . . . . . . . . . . . . . . . 107 4.15.3 Métrica VMAF (Video Multimethod Assessment Fusion - Fusão de Avaliação Multimétodo de Vídeo) . . . . . . . . . . . . . . . . . . . 108 4.16 Medidas da Qualidade Objetiva de Vídeo . . . . . . . . . . . . . . . 109 4.17 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 5 CONCLUSÕES 118 5.1 Atividades Realizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 xix 5.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 5.3 Artigos Publicados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 6 ANEXO 128 REFERÊNCIAS BIBLIOGRÁFICAS 144 xx 1 INTRODUÇÃO Diferentes sistemas de TV (Television - Televisão) digital terrestre sofreram atualiza- ções em suas especificações com propósito de acompanhar o desenvolvimento da tecnologia e incorporá-la. Por ex., o sistema ATSC (Advanced Television System Committee - Co- mitê de Sistema de Televisão Avançada) sofreu atualização da especificação ATSC 1.0 para a especificação ATSC 3.0 (ATSC, 2022). O sistema DVB (Digital Video Broadcas- ting - Transmissão de Vídeo Digital) sofreu atualização da especificação DVB-T para a especificação DVB-T2 (DVB, 2020). O sistema DTMB (Digital Terrestrial Multimedia Broadcast - Transmissão Multimídia Digital Terrestre) teve sua especificação atualizada para o sistema ADTMB (Advanced Digital Terrestrial Multimedia Broadcast - Transmis- são Multimídia Digital Terrestre Avançada) (DTMB, 2020). No Japão, a emissora NHK (Nippon Hoso Kyokai - Japan Broadcasting Corporation - Corporação de Radiodifusão do Japão) vem conduzindo diferentes tipos testes, tais como, testes de transmissão de vídeo UHD (Ulta High Definition - Definição Ultra Alta) 8K (4320p@60), utilização de diferentes técnicas de multiplexação de canal a fim de propor atualizações ao sistema ISDB-T (Integrated Services Digital Broadcasting - Terrestrial - Transmissão Digital de Serviços Integrados - Terrestrial) (SAITO et al., 2016). Neste contexto, o SBTVD (Sistema Brasileiro de Televisão Digital - Brazilian System of Digital Television) não deixaria de acompanhar o movimento de atualização, incorpo- rando as mais modernas tecnologias de codificação de áudio e vídeo, utilização de MW (Middleware - Camada Intermediária) híbrido entre outras. A partir do ano de 2018, após uma série de reuniões e discussões, o Fórum SBTVD aprovou uma série de aperfeiçoamentos ao atual SBTVD. Estas discussões tinham uma agenda evolutiva, retro-compatível com o atual sistema de TV digital, com objetivo de incorporar novas tecnologias e avanços a este sistema de TV digital, tais como: • Maior integração entre Internet e radiodifusão através do uso de um MW híbrido ou IBB (Integrated Broadcast Broadband - Transmissão Integrada com Banda Larga); • Novos formatos de áudio imersivo; 1 • Novas formatos de HDR (High Dynamic Range - Alta Faixa Dinâmica). Esta agenda ficou conhecida como TV 2.5. A maior integração entre Internet e radiodifusão levou à elaboração de um novo perfil de receptores MW Ginga, o Perfil D, também conhecido por DTV Play. As normas do Perfil D foram revisadas e publicadas pela ABNT (Associação Brasileira de Normas Técnicas - Technical Standards Brazilian Association) durante o ano de 2018 (SBTVD, 2023). Na parte da transmissão terrestre OTA (Over The Air - Através do Ar) foram in- corporados novos formatos de áudio imersivo, tais como MPEG (Motion Picture Experts Group - Grupo de Especialistas em Quadros de Movimento) H (BLEIDT et al., 2017), E-AC-3 e AC-4 (RIEDMILLER et al., 2017), bem como os formatos de HDR, compatíveis com sinal de vídeo de 8 bits: HLG (Hybrid Log-Gamma - Gamma Log Híbrida) (ITU-R, 2018) e SL-HDR1 (ETSI, 2017). As normas referentes à incorporação destes novos formatos de HDR e áudio foram revisadas pela ABNT, entrando em consulta nacional em Março 2020, sendo publicadas no mês de Maio do mesmo ano. A partir do mês de Abril de 2020 iniciaram-se as discussões, estudos e elaboração de requisitos que nortearão o desenvolvimento do novo sistema brasileiro de TV digital, também conhecido como TV 3.0. Com esta finalidade, estudos, comparativos, avaliação dos diferentes sistemas mundiais de TV digital, experimentos etc. foram realizados para propor o novo sistema de TV digital do Brasil (TV 3.0) (SBTVD, 2024). Apesar dos avanços incorporados no sistema TV 2.5 servirem de base para as discus- sões e avanços desejados para o novo sistema TV 3.0, este novo sistema de TV digital não tem compromisso de retro-compatibilidade com o sistema TV 2.5, sendo, portanto, um sistema disruptivo. Desta maneira, o Fórum SBTVD estabeleceu cinco GTs (Grupos de Trabalho) com a finalidade de elaborar os requisitos do novo sistema de TV digital a ser adotado pelo Brasil, conforme a seguir: 2 • GT-A/V (Audio and Video - Áudio e Vídeo) - Grupo de Trabalho - Working Group responsável pela elaboração dos requisitos de codificação de áudio e vídeo; • GT- Camada Física e Transporte - Grupo de Trabalho - Working Group responsável pela elaboração dos requisitos de camada física e camada de multiplexação; • GT de Acessibilidade - Grupo de Trabalho - Working Group responsável pela ela- boração dos requisitos de acessibilidade para pessoas portadores de necessidade especiais; • GT-EWBS (Emergency Warning Broadcast System - Sistema de Transmissão de Alerta de Emergência) - Grupo de Trabalho - Working Group responsável pela elabora- ção dos requisitos de aviso de especial de emergência em caso de situações de desastres naturais; • GT-MW (Middleware - Camada Intermediária) - Grupo de Trabalho - Working Group responsável pela elaboração dos requisitos de implementação do Middleware - Ca- mada Intermediária. Uma vez que todos os requisitos foram finalizados e acordados, o Fórum SBTVD pu- blicou em Julho de 2020 as CfPs (Call for Proposals - Chamada de Propostas), para todos os consórcios internacionais interessados em apresentar suas propostas de atendimento de requisitos (SBTVD, 2024). Paralelamente à publicação dos requisitos do novo sistema de TV digital através das respectivas CfPs, os GTs voltaram a se reunir a fim de elaborarem os procedimentos de testes para avaliação das soluções propostas para atendimento das CfPs. Os procedimentos de testes foram oficialmente publicados em Outubro de 2020, tendo sido revisados em Março de 2021 (SBTVD, 2024). Entre Janeiro e Março de 2021, todos os proponentes que propuseram soluções para o CfPs apresentaram durante as reuniões do Fórum SBTVD suas respetivas propostas e planos para o atendimento à fase de testes. Esta agenda ficou conhecida como Fase 1 da TV 3.0 (SBTVD, 2024). O Fórum SBTVD selecionou oito universidades brasileiras a fim de testar as soluções propostas, onde cada universidade ficou responsável por testar as soluções candidatas 3 pertinentes a uma camada específica do novo sistema (SBTVD, 2024): • Universidade Presbiteriana Mackenzie - responsável pela execução dos testes de laboratório das soluções candidatas referentes à camadas física e de transporte. • UFF (Universidade Federal Fluminense - Fluminense Federal University) - respon- sável pela execução dos testes de campo das soluções candidatas referentes à camada física. • UNB (Universidade de Brasília - University of Brasilia) - responsável pela execução dos testes de laboratório das soluções candidatas referentes à camada de vídeo. • USP (Universidade de São Paulo - University of São Paulo) - responsável pela execução dos testes de laboratório das soluções candidatas referentes à camada de áudio. • UFPB (Universidade Federal da Paraíba - Federal University of Paraiba) - respon- sável pela execução dos testes de laboratório das soluções candidatas referentes à camada de captions. • UFJF (Universidade Federal de Juiz de Fora - Federal University of Juiz de Fora) e PUC-RIO (Pontifícia Universidade Católica do Rio de Janeiro - Pontifical Catholic University of Rio de Janeiro) - responsáveis pela execução dos testes de laboratório das soluções candidatas referentes à camada de aplicações. No começo do segundo semestre de 2021, os equipamentos de testes cedidos pelos proponentes para avaliação de suas respectivas propostas foram entregues aos laboratórios de testes, permitindo o início da avaliação das tecnologias candidatas. Os testes foram concluídos ao final do segundo semestre de 2021 e os relatórios de testes entregues ao Fórum SBTVD. Embora quatro propostas de tecnologia de camada física tenham sido recebidas, con- forme listado a seguir, os testes destas propostas não foram conclusivos para a seleção de uma das tecnologias candidatas (SBTVD, 2024): 1. ATSC 3.0 - proposta pelo consórcio ATSC. 2. Advanced ISDB-T - proposta pelo consórcio DiBEG (Digital Broadcasting Experts Group - Grupo de Especialistas em Transmissão Digital). 4 3. 5G Broadcast - proposta pelo consórcio formado pelas empresas Qualcomm e Rhode Schwartz. 4. DTMB - Advanced - proposta pelo consórcio DTVNEL (National Engineering Lab. for DTV - Laboratório Nacional de Engenharia para TV Digital). Os equipamentos das tecnologias candidatas ATSC 3.0, DTMB-A e 5G Broadcast não operavam em condição de (C/N) <= 0 dB (reuso-1 de frequência), portanto, não permitindo que este requisito fosse testado. Os equipamentos de tecnologia Advanced ISDB-T operavam na condição de (C/N) <= 0 dB em somente um subconjunto de pontos dos testes de campo. Neste caso, foi alcançada uma taxa de transmissão de 3,6 Mbps em condição MIMO (Multiple Input Multiple Output - Múltiplas Entradas Múltiplas Saídas). Desta maneira, testes adicionais de laboratório e de campo serão necessários a fim de melhor avaliar as soluções propostas para a camada física. De forma semelhante a camada física, apesar de camada de transporte receber quatro propostas conforme listado a seguir, nem uma delas mostrou desempenho satisfatório durante a fase de testes (SBTVD, 2024): 1. ROUTE/DASH (Real Time Object Delivery over Unidirectional Transport - En- trega de Objetos em Tempo Real sobre Transporte Unidirecional/Dynamic Adaptive Streaming over HTTP - Fluxo Adaptável Dinâmico sobre HTTP) - proposta pelo consórcio ATSC. 2. MMT (MPEG Multimedia Transport - Transporte Multimídia MPEG) - proposta pelo consórcio ATSC. 3. SMT (Smart Media Transport - Transporte de Mídia Inteligente) - proposta pelo consórcio DTVNEL. 4. MMT - proposta pelo consórcio DiBEG (Digital Broadcasting Experts Group - Grupo de Especialistas em Transmissão Digital). As tecnologias ROUTE/DASH e MMT propostas pelo consórcio ATSC não puderam ser testadas devido a falta de equipamento apropriados. Nem todos os requirimentos 5 foram implementados nos equipamentos da tecnologia SMT (tais como TL1: Habilitar a sincronia de dados e A/V transportados na mesma, ou em diferentes plataformas de distribuição; e TL2: Facilitar a retransmissão de conteúdo em diferentes plataformas de distribuição e para a rede doméstica), desta forma, não permitindo que fossem testados. Os receptores de tecnologia MMT do DiBEG não podiam operar sem o setup de trans- missão/recepção de RF (Radio Frequency - Radiofrequência), desta maneira, impedindo o testes de algum requisitos (tais como TL1 e TL2). Apesar deste cenário, no começo do ano de 2022, as tecnologias ROUTE e DASH foram adotadas como soluções OTA/Internet respectivamente para a camada de transporte, uma vez que o protocolo ROUTE/DASH é a tecnologia mais madura dentre as tecnologias candidatas e sua latência tem diminuído ao passo que esta tecnologia amadurece (SBTVD, 2024). Do ponto de vista de codificação de vídeo, dois padrões de codificação de vídeo supor- tavam a funcionalidade de vídeo escalável: H.265 - HEVC (High Efficient Video Coding - Codificação de Vídeo de Alta Eficiência) e H.266 - VVC (Versatile Video Coding - Co- dificação Versátil de Vídeo). Sendo que o padrão de codificação H.265 não foi testado por ser considerado como âncora para comparação com as outras tecnologias candidatas, por ser uma tecnologia comercialmente madura e amplamente utilizada, ao passo que o padrão de codificação H.266 - VVC mostrou melhor performance durante os testes, sendo posteriormente adotado como padrão de codificação de vídeo (SBTVD, 2024). A Figura 1 oferece uma síntese das tecnologias que foram adotadas ao final do ano de 2021 para TV 3.0, conforme relatado nos parágrafos anteriores. Esta agenda ficou conhecida como Fase 2 da TV 3.0 (SBTVD, 2024). No primeiro semestre do ano de 2022, o Fórum SBTVD se dedicou a elaboração do procedimento de testes para avaliação subjetiva de codificação de vídeo, a fim de deter- minar a mínima taxa de transmissão necessária para transmitir o conteúdo de vídeo com qualidade mínima de 1080i@60, similar a da TV 2.5, para dimensionamento da camada física OTA. Assim como se dedicou elaboração de casos de uso, revisão e priorização dos requisitos para implementação das soluções pertinentes a camada de aplicação (SBTVD, 2024). 6 Figura 1: Tecnologias Adotadas pela TV 3.0 ao final do Ano de 2021. Fonte: (SBTVD, 2024). Durante o segundo semestre do ano de 2022, o Fórum SBTVD se dedicou à elaboração das normas das tecnologias candidatas que já foram adotadas e não necessitam de esforços adicionais de pesquisa e desenvolvimento, tais como: vídeo, HDR, áudio e captions. A partir de Abril de 2023, contando com financiamento da RNP (Rede Nacional de Ensino e Pesquisa) o Fórum SBTVD iniciou uma rodada adicional de testes de laboratório e de campo para avaliação das soluções candidatas de camada física, assim como os testes de avaliação subjetiva de vídeo. Esta fase adicional de testes terá duração de 18 meses. Finalizados os testes de camada física, o Fórum SBTVD se dedicará a elaboração das normas desta camada. Paralelamente à avaliação das tecnologias de camada física, o Fórum SBTVD está desenvolvendo as adaptações necessárias para utilização das tecnologias adotadas para a camada de transporte (ROUTE e DASH), assim como uma implementação de referência destas tecnologias. A elaboração da norma dos receptores de TV 3.0 foi iniciada em Outubro de 2023 e espera-se sua conclusão até Setembro de 2024. Esta agenda ficou conhecida como Fase 3 da TV 3.0 (SBTVD, 2024). 7 Em Abril de 2023 o governo brasileiro publicou o decreto Nº 11.484 (CIVIL, 2023), dispondo sobre as diretrizes para a evolução do SBTVD, cuja próxima geração é deno- minada TV 3.0. Sendo que no Art. 2º, parágrafo III, o decreto estabelece que a TV 3.0 será dotada da integração entre conteúdo transmitido pelo serviço de radiodifusão e pela Internet. Em Julho de 2023 o governo brasileiro publicou a portaria Nº 9.893 (COMUNICA- çõES, 2023), instituindo o Grupo de Trabalho TV 3.0, que congrega representantes dos diversos segmentos da sociedade brasileira, como Agência Nacional de Telecomunicações, Fórum Sistema Brasileiro de Televisão Digital, Ministério da Fazenda, Ministérios da Ci- ência e Tecnologia, Ministério das Comunicações e setor de radiodifusão, com a finalidade de propor a regulamentação aplicável à TV 3.0, nos termos do Art. 6º do Decreto Nº 11.484. O GT TV 3.0 tem como atribuições, entre outras, propor a regulamentação técnica e de serviço aplicável à TV 3.0, padrão tecnológico da TV 3.0, propor modelo de implanta- ção, acompanhar os testes dos padrões tecnológicos e propor o cronograma de implantação e transição para a TV 3.0 O lançamento oficial da nova geração de TV digital brasileira é esperado para o ano de 2025 e a transição completa do atual sistema de TV digital brasileiro para a TV 3.0 tem duração esperada de ao menos 15 anos (SBTVD, 2024). Paralelamente aos avanços da TV digital, de acordo com a ANATEL (Agência Nacio- nal de Telecomunicações - National Telecommunications Agency) o número de assinantes de pacotes de Internet Banda Larga Fixa tem crescido fortemente no Brasil ao longo dos últimos 10 anos (ANATEL, 2024). A Figura 2 ilustra o ritmo de crescimento de assinaturas de banda larga fixa no Brasil. O total de assinaturas (linha azul clara) saltou de aproximadamente 17 milhões de assinaturas em Dezembro de 2011 para mais de 47 milhões em Dezembro de 2023. Ao passo que o crescimento de assinaturas de cable modem (linha laranja) aproxi- madamente dobrou nesta janela de tempo, o volume de assinaturas da tecnologia xDSL (Digital Subscriber Line - Linha Digital de Assinante) (linha azul escura) teve seu auge entre Dezembro de de 2014 e Dezembro de 2018, atingindo pouco mais de 13 milhões de 8 Figura 2: Crescimento do Número de Assinaturas de Internet Banda Larga no Brasil - Tecnologia. Fonte: (ANATEL, 2024). assinaturas, iniciando uma queda desde então, diminuindo em mais de 70% a quantidade de assinaturas até Dezembro de 2023. Além disso, o volume de assinaturas de planos de fibra óptica (linha cinza) ultrapassou seu primeiro milhão de assinaturas em Dezembro de 2014, crescendo pouco mais de 10 vezes em 6 anos, finalmente, ultrapassando a quantidade de assinaturas da tecnologia xDSL em Dezembro de 2020. A quantidade de assinaturas das outras tecnologias de acesso a redes banda larga (linha amarela) representam cerca de 4% do total de assinaturas de banda larga em Dezembro de 2023. Além do crescimento do volume de assinaturas de banda larga, cresce também a ve- locidade de acesso ofertada pelas operadoras de telecomunicações, bem como o respectivo volume de assinaturas nas velocidade mais elevadas, em especial, o volume de assinantes do serviço de fibra óptica (ANATEL, 2024). Conforme verifica-se na Figura 3, planos com velocidade de acesso superior a 34 Mbps (linha azul escura), tiveram um crescimento explosivo a partir de de Dezembro 2014, sendo 9 a velocidade de acesso mais assinada a partir de Dezembro de 2019 (ANATEL, 2024). Figura 3: Crescimento do Número de Assinaturas de Internet Banda Larga no Brasil - Velocidade de Conexão. Fonte: (ANATEL, 2024). Paralelamente, outros planos com menores velocidades de acesso, até 34 Mbps (linha laranja) e até 12 Mbps (linha cinza), após um crescimento inicial, trilham desde Dezembro de 2019 uma rota de decrescimento. Os planos com velocidade de até 2 Mbps (linha amarela) tem seu volume de assinaturas decrescendo fortemente desde Dezembro de 2012 (ANATEL, 2024). Em Dezembro de 2023, o Brasil possuía 42,871 milhões de assinaturas de Internet Banda Larga Fixa contratadas por pessoas físicas e 5,654 milhões de assinaturas de In- ternet Banda Larga Fixa contratadas por pessoas jurídicas (ANATEL, 2024). 1.1 Justificativa Grandes projetos devem ser desenvolvidos no Brasil, principalmente em se tratando do SBTVD. A tecnologia de vídeo escalável é um recurso que já é utilizado pelas gerações mais avançadas de TV digital terrestre, como o ATSC 3.0 (ATSC, 2022), o DVB-T2 (DVB, 10 2020) e que deverá estar presente na próxima geração de TV digital japonesa (Mochida et al., 2019). Assim sendo, esta tecnologia pode ser explorada no âmbito do SBTVD de diferentes maneiras: 1. Prover o mesmo conteúdo, entretanto com resoluções diferentes para dispositivos móveis e fixos, explorando ao máximo os recursos oferecidos por cada tipo de recep- tor de TV, oferecendo ao usuário uma melhor experiência de utilização (ISDB-T, 2020); 2. Prover uma melhor experiência de utilização para usuários de receptores fixos e com capacidade de resolução UHD 4K (2160p@30), devido ao enriquecimento do conteúdo de vídeo recebido através do recurso de vídeo escalável (Hulusic et al., 2017). 1.2 Objetivos 1.2.1 Objetivo Geral Avaliar as características de escalabilidade de vídeo do padrão de codificação MPEG- H - Parte 2/ ITU-T (International Telecommunication Union - Standardization Sector - União Internacional de Telecomunicações - Setor de Padronização) - H.265 - SHVC (Scalable High Video Coding - Codificação de Alta Eficiência de Vídeo Escalável), com resolução base de vídeo de FHD (Full High Definition - Alta Definição Completa) 2K (1080p@30) sendo transmitida pelo sinal de TV terrestre OTA e com enriquecimento de FHD 2K (1080p@30) para UHD 4K (2160p@30) via Internet 1.2.2 Objetivos Específicos 1. Realizar a revisão da literatura dos diferentes padrões de codificação de vídeo já existentes e em desenvolvimento. 2. Pesquisar e analisar os diferentes padrões de multiplexação de áudio e vídeo já existentes e em desenvolvimento. 11 3. Propor solução de transmissão de vídeo com camada base transmitida pelo sinal de TV terrestre OTA e com a camada de enriquecimento via Internet para utilização no próximo padrão de sistema de TV digital terrestre brasileiro. Passos a seguir para proposição da solução: (a) Codificar vídeos de referência em SHVC. (b) Utilizar a camada de transporte ROUTE/DASH para transporte do conteúdo SHVC e avaliação da latência imposta pela camada de transporte em diferentes situações. (c) Transmitir conteúdo da camada de transporte ROUTE/DASH com um único PLPs na camada física do ATSC 3.0. (d) Avaliar subjetivamente a mudança de resolução espacial na transmissão e re- cepção. (e) Avaliar objetivamente a mudança de qualidade de vídeo do conteúdo de vídeo de camada básica FHD 2K (1080p@30), recebido pelo sinal de TV terrestre OTA, para o conteúdo enriquecido, composto pelo fluxo de vídeo da camada básica e da camada de enriquecimento UHD 4K (2160p@30), recebido via Internet, através de indicadores como VMAF (Video Multimethod Assessment Fusion - Fusão de Avaliação Multimétodo de Vídeo), PSNR (Peak Signal-to- Noise Ratio - Relação Sinal Ruído de Pico) e SSIM (Structural Similarity Index Measure - Medida do Índice de Similaridade Estrutural). 1.3 Metodologia Adotada nesta Tese Esta tese foi desenvolvida através do levantamento e estudo do estado da arte com base em artigos científicos publicados em revistas indexadas e congressos, além de livros e normas técnicas pertinentes. Com base no estado da arte levantado e no momento do desenvolvimento da TV digital brasileira, foi elaborada a proposta de trabalho. Desta maneira, propondo-se os experimento científicos pertinentes. Os experimentos propostos foram executados através da utilização dos equipamentos 12 de TV digital e computadores pertencentes ao Laboratório de TV Digital da Escola de Engenharia da Universidade Presbiteriana Mackenzie. O computadores utilizados no desenvolvimento deste trabalho possuem tanto sistema operacional Windows, como Linux. Os programas e ambientes computacionais desenvolvidos no âmbito desta tese foram escritos em linguagem de programação C++, sendo executado em sistema operacional Linux. O analisador de pacotes foi desenvolvido em linguagem Lua, sendo executado sobre o sistema operacional Windows. 1.4 Estrutura da Tese Esta tese é estruturada em 5 capítulos, a saber: • O Capítulo 1 apresenta uma introdução ao escopo deste trabalho, destacando prin- cipalmente as motivações, relevância, objetivos e resultados esperados deste trabalho; • O Capítulo 2 apresenta o estado da arte da parte dos padrões de codificação de vídeo; • O Capítulo 3 apresenta o estado da arte da parte de multiplexação de conteúdos multimídia; • O Capítulo 4 apresenta a proposta de pesquisa desta tese bem como os resultados experimentais obtidos; • O Capítulo 5 apresenta as considerações finais desta tese; 13 2 CODIFICAÇÃO DE VÍDEO Neste capítulo são apresentados conceitos de escalabilidade de vídeo, além dos princi- pais tipos de escalabilidade existentes, apresentando o estado da arte dos padrões de codi- ficação de vídeo com suporte a escalabilidade, partindo do padrão MPEG (Motion Picture Experts Group - Grupo de Especialistas em Quadros de Movimento) 2 – Parte 2/ITU-T (International Telecommunication Union - Standardization Sector - União Internacional de Telecomunicações - Setor de Padronização) - H.262, abordando os padrões MPEG-4 – Parte 2, MPEG-4 – Parte 10/ITU-T H.264 - AVC (Advanced Video Coding - Codificação Avançada de Vídeo), MPEG-H – Parte 20/ITU-T H.265 - HEVC (High Efficient Video Coding - Codificação de Vídeo de Alta Eficiência), MPEG-I – Parte 3/ITU-T H.266 - VVC (Versatile Video Coding - Codificação Versátil de Vídeo), MPEG-5 – Parte 1/EVC (Essential Video Coding - Codificação de Vídeo Essencial), MPEG-5 – Parte 2/LCEVC (Low Complexity Enhancement Video Coding - Codificação de Vídeo Aprimorada de Baixa Complexidade). 2.1 Introdução A tecnologia de vídeo digital possui diversos benefícios, entretanto, é acompanhada de diversos desafios, sendo os principais deles os desafios de armazenamento e transmissão de dados. Uma sequência de vídeo digital com boa qualidade requer um grande espaço de armazenamento em disco, além de uma razoável taxa de transmissão para ser trans- portado. A taxa de transmissão necessária para transmitir o vídeo digital é proporcional da resolução espacial, taxa de quadros, quantidade de bits utilizados por amostra e número de amostras de crominância e luminância utilizadas, conforme a Equação 1: TaxTrans = ResHor ×ResV er × TaxRef × BitAmom× AmoCromLum (1) Onde a TaxTrans é a taxa de transmissão do vídeo não comprimido, ResHor é a resolução horizontal de vídeo, ResVer é a resolução vertical de vídeo, TaxRef é a taxa de 14 quadros ou refrescamento de vídeo, BitAmom é a quantidade de bits por amostra de vídeo e AmoCromLum é o número de amostras de crominância. Por ex., considerando-se a necessidade de transmissão do sinal colorido de vídeo digital com a resolução de vídeo UHD 4K, com resolução de (2160p@60), razão de aspecto de 16:9, 10 bits por pixel utilizado pelo sistema estado unidense de TV digital ATSC 3.0 (ATSC, 2022) necessitando de uma taxa de transmissão de aproximadamente 15 Gbps, conforme calculado no exemplo numérico a seguir: 2160 × 3840× 60× 10× 3 = 14.929.920.000 bps O desafio torna-se maior ainda quando considerado o sinal UHD 8K, de resolução de vídeo (4320p@60), razão de aspecto de 16:9, 10 bits por pixel candidata às próximas gerações de TV digital japonesa e brasileira, necessitando-se de aproximadamente 60 Gbps, conforme calculado no exemplo numérico a seguir: 4320 × 7680× 60× 10× 3 = 59.719.680.000 bps Estes valores de taxa de transmissão são impraticáveis, mesmo se considerados os atuais planos comerciais de acesso à Internet com maiores velocidade de acesso, por ex., nas velocidades de 750 Mbps ou 1 Gbps (ANATEL, 2024). Este quadro se torna ainda mais desafiador se consideradas as taxas de transmissão alcançadas pelos atuais sistemas de TV digital, como o SBTVD com taxa de transmissão máxima de 23 Mbps (SBTVD, 2023), ou como o ATSC 3.0 com taxa de transmissão máxima de 57 Mbps (ATSC, 2022). Evidencia-se, portanto, a necessidade da codificação do conteúdo de vídeo considerando- se a necessidade de armazenamento e transmissão deste. Codificação de vídeo é o processo de compressão e descompressão do sinal de vídeo digital (RICHARDSON, 2003). Este processo tem por objetivo a redução da redundância dos dados de forma a armazenar ou transmitir esses mesmos dados de forma eficiente. Processos de compressão de vídeo com perdas de dados são utilizados nos casos em que a redução da imagem para fins de transmissão e armazenamento são mais importantes do que a qualidade, sem no entanto, menosprezá-la. 15 Este recurso é utilizado, por ex., em máquinas fotográficas digitais, que capturam mais informação do que o olho humano detecta, utilizando este comportamento para remoção de redundâncias da imagem (temporal, espacial entre outras) e assim diminuir o seu tamanho. Este tipo de técnica de compressão de imagem normalmente proporciona uma taxa de compressão de informação normalmente entre 50:1 e 100:1 (JPEG, 2020), (JPEG, 1995). Diferentes padrões de compressão de imagens/vídeos (com perdas de dados) foram propostos e padronizados ao longo dos anos, baseando-se em diferentes premissas, algo- ritmos e princípios. A linha do tempo apresentada na Figura 4 apresenta de forma resu- mida a história dos padrões de codificação de vídeo padronizados pelos ITU (International Telecommunication Union - União Internacional de Telecomunicações) e ISO/IEC (Inter- national Organization for Standardization/International Electrotechnical Commission - Organização Internacional para Padronização/Comissão de Eletrotécnica Internacional), com respectivos marcos temporais de lançamento ou previsão de lançamento, desde o padrão ITU-T - H.261 até o padrão MPEG-5 - Parte 2 LCEVC. A Figura 4 ilustra um breve histórico dos principais padrões de codificação de vídeo concebidos pelos ISO-IEC e ITU-T desde a década de 1980 até os dias atuais. As principais características destes padrões de codificação de vídeo são enumerados nas seções a seguir. Figura 4: Histórico dos Padrões de Codificação de Vídeo. Fonte: (Wien; Ohm, 2018). 16 2.2 Escalabilidade de Vídeo Em geral, um fluxo de bits de vídeo é chamado escalável quando partes do bitstream podem ser removidas de uma forma que o sub-fluxo resultante forme outro bitstream válido para algum decodificador específico e o sub-fluxo representa o conteúdo fonte com uma qualidade de reconstrução inferior àquela do fluxo de bits original completo, mas é alto quando considera-se a menor quantidade de dados restantes. Os bitstreams que não fornecem essa propriedade são chamados de fluxos de bits de camada única (Schwarz; Marpe; Wiegand, 2007). Um fluxo de dados de vídeo escalável é arranjado em um número de camadas (layers), incluindo uma camada base ou BL (Base Layer - Camada Base) e uma ou mais camadas de enriquecimento ou EL (Enhancement Layer - Camada de Enriquecimento). Na Figura 5 o decodificador A recebe somente a camada base, decodificando-a com qualidade básica de vídeo. Ao passo que o decodificador B recebe todas as camadas de vídeo decodificando-as como um vídeo de alta qualidade. Figura 5: Conceito Geral de Codificação Escalável. Fonte: (RICHARDSON, 2003). A codificação de vídeo escalável provê um mecanismo para codificação de vídeo em múltiplas camadas, onde cada camada representa uma qualidade diferente da mesma cena de vídeo. O BL é a representação de qualidade mais baixa. Uma ou mais ELs podem ser codificadas referenciando-se as camadas inferiores e prover qualidade de vídeo aprimorada. A decodificação de um subconjunto de camadas de um bitstream de vídeo escalável resulta em vídeo com qualidade inferior, mas ainda aceitável, do que resultaria se o bitstream completo fosse decodificado. Isso permite uma degradação mais sutil nos ELs em comparação com bitstream de vídeo não escalável, onde a redução na taxa de 17 bits normalmente causa degradações mais graves na qualidade do vídeo, muitas vezes tornando-se rapidamente de qualidade inaceitável para visualização. As aplicações que usam codificação de vídeo escalável podem beneficiar-se da capaci- dade de adaptar o bitstream de vídeo de acordo com os requisitos dos decodificadores e as condições das redes de dados. Tais aplicações incluem videoconferência e streaming de vídeo em redes com e sem fio. Alguns decodificadores de vídeo têm complexidade compu- tacional limitada e optam por decodificar apenas camadas de resolução inferior. Algumas redes têm largura de banda limitada ou variável e podem reduzir a largura de banda do fluxo de bits de vídeo descartando o EL enquanto encaminha as camadas inferiores para o decodificador (Boyce et al., 2016). Por ex., considerando-se um cenário de um serviço de transmissão de vídeo com cli- entes heterogêneos, onde múltiplos bitstreams do mesmo conteúdo fonte, que diferem no tamanho da imagem codificada, taxa de quadros e taxa de transmissão, devem ser forneci- dos simultaneamente (simulcasting). Utilizando-se o recurso de vídeo escalável, o conteúdo da fonte deve ser codificado apenas uma vez - nas resolução e taxa de transmissão mais altas exigidas, resultando em um bitstream escalável a partir do qual representações com resolução e/ou qualidade mais baixas podem ser obtidas descartando dados selecionados. Por ex., um cliente com recursos restritos (resolução de tela, poder de processamento ou capacidade da bateria) precisa decodificar apenas uma parte do bitstream recebido (Schwarz; Marpe; Wiegand, 2007). A resiliência a erros é uma outra característica importante da codificação de vídeo escalável. Os erros de rede que levam à perda de dados da EL causam muito menos degradação da qualidade do vídeo do que a perda de dados não escaláveis. A proteção desigual contra erros pode ser usada em combinação com a codificação de vídeo escalável para fornecer maior proteção às camadas inferiores do que as ELs. Quando o codificador de vídeo escalável provê a capacidade de upswitching de uma camada inferior para uma camada superior no bitstream, um decodificador de vídeo pode se recuperar totalmente de uma perda anterior na camada superior. Historicamente, são definidos três tipos principais de escalabilidade de vídeo (Boyce et al., 2016): • Escalabilidade Espacial: Um fluxo de transporte de camada base BL carrega imagem 18 principal, codificada com baixa resolução, enquanto outros fluxos (ELs) independentes carregam informações para reconstrução de imagem com resolução completa. A escalabilidade espacial permite a extração de bitstreams com diferentes resoluções espaciais a partir do bitstream completo. Esta técnica permite oferecer conteúdos de resolução espacial a partir do mesmo fluxo a terminais com diferentes características. Este conceito é ilustrado na Figura 6 (a) e (b), onde o bitstream está dividido em duas camadas de escalabilidade espacial. Através da decodificação da primeira camada (BL), o dispositivo obtém uma versão da imagem ou vídeo original com a menor resolução espacial possível - Figura 6 (a). A decodificação da segunda camada de escalabilidade (EL) permite obter mais informações que, adicionadas à primeira camada (BL), resulta em uma imagem reconstruída com resolução original (máxima resolução espacial) - Figura 6 (b) . Figura 6: Escalabilidade Espacial. (a) Baixa Resolução (b) Alta Resolução. Fonte: (Vaz et al., 2023a). • Escalabilidade Temporal: A camada base BL de uma sequência de escalabilidade temporal é codificada com baixa taxa de quadros (low frame rate) e uma camada de enriquecimento EL temporal que pode ser decodificada junto com a camada base para aumentar a taxa de quadros de vídeo. Este conceito é ilustrado na Figura 7 (a) e (b), onde o bitstream está dividido em duas camadas de escalabilidade temporal, o que permite a extração de bitstreams correspon- 19 Figura 7: Escalabilidade Temporal. (a) Baixa Taxa de Quadros (b) Alta Taxa de Quadros. Fonte: (Vaz et al., 2023a). dente as diferentes resoluções temporais a partir do bitstream completo. A decodificação da primeira camada (BL) resulta numa versão do vídeo com baixa resolução temporal - Figura 7 (a) - e a decodificação progressiva das camadas restantes EL permite um aumento gradual da resolução temporal - Figura 7 (b). Uma técnica de codificação escalável deve permitir uma qualidade visual excelente na resolução temporal máxima, mas também manter uma qualidade visual aceitável nas resoluções temporais mais baixas. • Escalabilidade de Qualidade ou de Relação Sinal/Ruído (S/N) (Signal-to-Noise Ra- tio - Relação Sinal Ruído Escalability - SNR): O fluxo principal carrega os coeficientes mais importantes da DCT (Discrete Cosine Transform - Transformada Discreta do Cos- seno), permitindo a reconstrução de uma imagem básica com baixa relação S/R e os fluxos secundários transportam os coeficientes adicionais. Conforme ilustrado na Figura 8 (a) e (b), em que o bitstream está dividido em duas camadas de escalabilidade SNR, permitindo-se a extração de bitstreams correspondentes a diferentes níveis de qualidade a partir do bitstream completo. Este tipo de escalabilidade também chamada escalabilidade de qualidade, uma vez que o erro de decodificação está relacionado com a qualidade perceptual da imagem. Desta maneira, há um aumento da qualidade da imagem ou vídeo sem variação das resoluções espacial e temporal. Este tipo de escalabilidade codifica sucessivamente o erro de codificação entre a ima- 20 gem original e a sua reconstrução numa dada camada. Figura 8: Escalabilidade de Qualidade de Imagem. (a) Baixa Qualidade (b) Alta Qualidade. Fonte: (Vaz et al., 2023a). Além destes tipos tradicionais, outras formas de escalabilidade mais recentes podem ser encontradas no âmbito da literatura científica (Boyce et al., 2016): • Escalabilidade Granular Fina (FGS - Fine Granular Scalability - Escalabilidade Granular Fina): Método de codificar uma sequência como BL e uma EL, onde a EL pode ser truncada durante ou após a codificação de vídeo (reduzindo a taxa de transmissão de dados de vídeo e a qualidade de decodificação) a fim de fornecer controle flexível e elevado sobre a taxa de transmissão de vídeo. FGS pode ser útil para aplicações de fluxo de vídeo, no qual a banda de transmissão pode não ser conhecida antecipadamente. Em um cenário típico, uma sequência de vídeo é codificada como BL e uma EL de alta qualidade. Após receber uma requisição de envio da sequência de vídeo em uma determinada taxa de transmissão, o servidor do fluxo de vídeo transmite a BL e uma versão truncada da EL. O montante truncado é escolhido a fim de casar a taxa de transmissão de vídeo disponível, consequentemente, maximizando a qualidade da sequência decodificada sem a necessidade de re-codificação. • Escalabilidade de Codificador Híbrido (Hybrid Codec): Consiste na possibilidade de utilizar diferentes padrões de codificação de vídeo no BL e EL provendo retrocompati- bilidade entre eles. Desta maneira o receptor não compatível com o codec do EL pode decodificar o conteúdo de vídeo normalmente. Um receptor compatível com ambos co- decs, ao combinar ambas camadas de vídeo, tem como resultado conversão do codec do 21 BL no codec do EL. Desta maneira, gozando dos benefícios propostos pelo codec do EL. Normalmente, nesse caso, o codec do BL é um codec de geração mais antiga, como o ITU-T H.264 - AVC e o codec do EL um codec de geração posterior, como o SHVC. A escalabilidade do codec híbrido permite ao SHVC ter expandido o suporte à retro- compatibilidade a codecs de gerações anteriores. • Escalabilidade de Profundidade de Cor (Bit Depth): A implantação de vídeo UHD, que possui maior profundidade de cores e gama de cores mais ampla (Wide Color Gamut) em relação a vídeos FHD, despertou muito interesse comercial para fornecer compatibi- lidade com versões de video anteriores, novos tipos de escalabilidade, como CGS (Color Gamut Scalability - Escalabilidade de Gama de Cor), se tornam interessantes. Normalmente, o vídeo FHD utiliza 8 bits de profundidade de cor, enquanto o vídeo UHD utiliza 10 bits. Portanto, BL pode transmitir vídeo de 8 bits e conteúdo adicional do EL dados adicionais para enriquecer o vídeo de 8 bits em vídeo de 10 bits. • Escalabilidade de Gama de Cores (Color Gamut): CGS, onde o BL possui uma gama de cores mais estreita, por ex., recomendação BT.709 (ITU-R, 2015b) e o EL possui uma gama de cores mais ampla, por ex., a recomendação BT.2020 (ITU-R, 2015a). 2.3 Formatos de Codificação de Vídeo ITU/ISO/IEC 2.3.1 Padrão JPEG ou JPG O formato de compressão de imagens JPEG (Joint Photographic Experts Group - Grupo Conjunto de Especialistas Fotográficos) é seguramente um dos formatos dedicado à compressão de imagens estáticas mais difundidos e utilizados atualmente. O grupo de trabalho JPEG foi estabelecido conjuntamente pela ISO/IEC e ITU-T ao final da década de 1980 com finalidade de desenvolver um padrão de compressão de imagem, que recebeu o mesmo nome do grupo de trabalho (JPEG, 1995) e (JPEG, 2020). O padrão JPEG, sintetizado pela recomendação ISO/IEC 10918-1, especifica diversos processo de compressão para imagens estáticas, incluindo um método de compactação sem perda, baseado em DPCM (Differential Pulse-Code Modulation - Modulação por Código de Pulso Diferencial). A principal base do processo de compactação com perdas é a DCT 22 (Discrete Cosine Transform - Transformada Discreta do Cosseno), que tem por objetivo a diminuição da correlação espacial entre as amostras, seguida da quantização variável e codificação estatística (ou de Huffman). A DCT, assim como outras transformadas espaciais, decompõem um bloco da imagem original na forma de uma soma ponderada de funções-base, ortonormais entre si. Nesta etapa a informação contida na imagem é analisada e reagrupada em coeficientes relaciona- dos ao conteúdo espectral da imagem. As perdas (bem como a maior parte da compressão efetiva da informação) do processo são determinadas pela etapa de quantização e a taxa de compressão pode ser aumentada, em detrimento da qualidade, ajustando-se um fator de escala do quantizador. Deve-se observar que o padrão JPEG destina-se à compressão de imagem com tona- lidades continua, como por ex. as obtidas através de processos fotográficos a partir de objetos reais. Não sendo adequado a compressão de imagens de alto contrastes e resolução, como por ex., textos e desenhos técnicos (JPEG, 1995) e (JPEG, 2020). 2.3.2 Padrão MPEG-1 - Parte 2 O Grupo MPEG é um grupo de trabalho formado pelas ISO/IEC com a finalidade de definir normas e padrões de compressão e transmissão de áudio e vídeo digitais. O primeiro padrão de codificação de vídeo a ser definido pelo grupo MPEG foi o padrão MPEG-1 - Parte 2 (RICHARDSON, 2003). Este formato de codificação de vídeo híbrido (que utiliza ferramentas de compressão sem perdas DPCM e ferramentas de compressão com perdas DCT), sintetizado na norma ISO/IEC 11172-2, teve sua primeira publicação em 1993 e é destinado a codificação de vídeo não entrelaçado, com taxas de transmissão de até 1,5 Mbps, como por ex., vídeo conferência em redes de dados E1/T1, além da compressão e armazenamento do sinal de vídeo com qualidade VHS (Video Home System - Sistema Doméstico de Vídeo) em CD-ROM (Compact Disc Read Only Memory - Disco Compacto com Memória Apenas de Leitura). O padrão MPEG-1 - Parte 2 é fortemente baseado no padrão H.261, mas não retro- compatível com este, onde a imagem, formatada tipicamente com resolução de 320 x 240 23 pixels, é subdividida em blocos de 8 x 8 pixels, estes blocos são agrupados em 4 blocos formando macroblocos (16 x 16 pixels), para fins de detecção de movimento, gerando vetores de movimentos a serem transmitidos ao receptor. Estes mesmos vetores são para produção da estimativa dos blocos a serem codificados, com base em na imagem anterior de referência. Sobre o erro produzido é aplicada a DCT, seguida da quantização variável e codificação estatística (MPEG, 1993). Macroblocos horizontalmente agrupados formam uma Fatia (ou Slices), que agrupados de forma consecutiva formam um quadro ou imagem. O padrão MPEG-1 define três tipos de imagens ou quadros (frames) (MPEG, 1993): • Quadro I (Intra-Frame - Intra-quadro ou Independente): Codificado sem predição de movimento, utilizando somente DCT, sendo um processo muito similar ao JPEG; • Quadro P (Predicted-Frame - Quadro Previsto ou com predição progressiva de mo- vimento): são reconstruídas através de predição de movimento, baseando-se em imagens de referência anteriormente codificadas, que podem ser do tipo I ou P, apresentando taxa de compressão elevada; • Quadro B (Bidirectional-Frame - Quadro Bidirecional ou com predição bidirecional): O preditor baseia-se em duas imagens de referência (anterior e posterior, tipo I ou P), admitindo até dois conjuntos de vetores de movimento (progressivo e regressivo) para cada bloco, sendo que neste caso a estimativa adotada a média das estimativas individuais, apresentando a maior taxa de compressão entre os três tipos de as imagens. Uma sequência de vídeo é subdivida em GOPs (Group of Pictures - Grupo de Ima- gens), que podem conter imagens do tipo I, P e B, é fechado se as predições de movimento das suas imagens são efetuadas sem necessitar de quadros de referência externos ao grupo, assim sendo, sequências de vídeo podem ser montadas tomando-se como pontos de corte os inícios destes GOPs. A estrutura de um GOP pode ser caracterizada pelos parâmetros M (distância entre imagens do tipo I) e N (distância entre imagens do tipo P), sendo comum adotar-se uma imagem do tipo I a cada 15 quadros. Este tipo de estrutura é ilustrada na Figura 9, utilizando-se configuração típica de quadros IBBPBBPBB com M = 9, N = 3. 24 Figura 9: Estrutura de um GOP Fonte: (STOLFI, 2020), (MPEG, 1993). Deve-se observar que a sequência de transmissão é diferente da sequência efetiva de exibição das imagens, uma vez que o receptor necessita dos quadros I e P (1 e 4) para reconstruir os quadros B intermediários (2 e 3). A Figura 10 exibe a estrutura hierárquica dos elementos de vídeo do padrão , ilus- trando seus diferentes elementos: Bloco, Macrobloco, Fatia (slice), Imagem, GOP e Sequência. A norma do padrão MPEG-1 - Parte 2 não especifica de forma detalhada a estrutura do codificador ou decodificador, apenas definindo a sintaxe do seu fluxo de dados e as ações a serem realizadas de acordo com os dados recebidos, deixando margem a diferentes tipos de implementação, com diferentes níveis de desempenho (BENOIT, 2008). 2.3.3 Padrão MPEG-2 – Parte 2/ITU-T H.262 O formato de codificação de vídeo híbrido (DPCM/DCT) MPEG-2 - Parte 2/ITU- T H.262 foi publicado inicialmente em 1995, conjuntamente pelo ITU-T e pelo MPEG ISO/IEC 13818-2, com o objetivo de codificar sinais de vídeo para aplicações genéricas, como multimídia, vídeo conferência até sinal de TV de alta definição ou HDTV (High Definition Television - Televisão de Alta Definição) para aplicações de radiodifusão, in- 25 Figura 10: Estrutura Hierárquica dos Elementos do Vídeo MPEG-1. Fonte: (STOLFI, 2020), (MPEG, 1993). cluindo recursos para codificação de imagens entrelaçadas, o que não estava disponível nos padrões de codificações de vídeo publicados até então. Além de englobar os recursos de codificação de vídeo definidos pelo padrão MPEG-1, o padrão MPEG-2 – Parte 2/ITU-T H.262 descreve um amplo conjunto de ferramentas de codificação de vídeo, de forma que dificilmente uma aplicação suportará todas as ferramentas de codificação de vídeo definidas pelo padrão. Desta maneira o padrão MPEG-2 - Parte 2/ITU-T H.262 define um conjunto de três perfis e quatro níveis de utilização destinados a diversos tipos de aplicações. Sendo os três perfis definidos pelo padrão MPEG-2 - Parte 2/ITU-T H.262: SP (Simple Profile - Perfil Simples), MP (Main Profile - Perfil Principal) e 4:2:2 Profile e os 4 níveis definidos: LL (Low Level - Nível Baixo), ML (Main Level - Nível Principal), High 1440 e HL (High Level - Nível Alto) (DAVIDSON et al., 2006). Um perfil define um conjunto de recursos relacionados com processamento e comple- xidade dos codificadores. Um nível limita a utilização de memória e o processamento necessários pela aplicação, definindo formato de vídeo, taxa de transmissão de vídeo etc (RICHARDSON, 2003). 26 Por ex., a combinação SP@LL corresponde a um codificador com desempenho equi- valente ao padrão MPEG-1 para multimídia. A combinação MP@ML é um formato adequado para TV convencional entrelaçada. O formato MP@HL é adequado para radiodifusão de HDTV (DAVIDSON et al., 2006). • Escalabilidade O padrão MPEG-2 - Parte 2/ITU-T H.262 admite perfis com suporte a três tipos de escalabilidade (Domanski; Mackowiak, 2001): • Escalabilidade Espacial • Escalabilidade Temporal • Escalabilidade de Qualidade ou de Relação Sinal/Ruído O padrão MPEG-2 - Parte 2/ITU-T H.262 define alguns perfis com suporte a es- calabilidade, tais como: SNRP (SNR Scalable Profile - Perfil Escalável em SNR), SpSP (Spatially Scalable Profile - Perfil com Escalabilidade Espacial), HP (High Profile - Perfil Alto) e MVP (Multi-View Profile - Perfil de Visualização Múltipla) (VCEG, 1995). 2.3.4 Padrão MPEG-4 - Parte 2 O padrão MPEG-4 - Parte 2, publicado inicialmente em 1998 pelo MPEG ISO/IEC 14496 - Parte 2, baseia-se, assim como todos os outros padrões de codificação de vídeo enumerados até o momento por esta tese, no modelo híbrido (DPCM/DCT). Uma das contribuições chave do padrão MPEG-4 - Parte 2 é o tratamento da sequência de vídeo como uma coleção de um ou mais VOs (Video Object - Objeto de Vídeo). O padrão MPEG-4 - Parte 2 define um VO como uma entidade flexível que um usuário tem acesso permitido e pode manipulá-lo. Um VO objeto de vídeo é uma área da cena de vídeo que pode ocupar uma região de forma arbitrária e pode existir por um intervalo de tempo arbitrário. Uma instância do VO em um momento particular de tempo é chamado de VOP (Video Object Plane - Plano de Objeto de Vídeo). Desta maneira o receptor pode manipular separadamente o fluxo de dados de vídeo proveniente de cada codificador, permitindo a visualização apenas dos objetos de vídeo 27 selecionados. Assim como o padrão MPEG-2 - Parte 2/ITU-T H.262, o padrão MPEG-4 - Parte 2 descreve uma grande variedade de ferramentas de codificação de vídeo, tornando impro- vável a implementação de todas as ferramentas de codificação de vídeo por uma aplicação. De maneira similar ao padrão MPEG-2 - Parte 2/ITU-T H.262, o MPEG- 4 - Parte 2 define um conjunto de perfis e níveis de utilização destinados a diversos tipos de aplicações. Os principais perfis definidos pelo padrão o MPEG- 4 - Parte 2 são os SP, ASP (Advanced Simple Profile - Perfil Simples Avançado), ARTSP (Advanced Real Time Simple Profile - Simples de Tempo Real Avançado), CPR (Core Profile - Perfil Cerne), MP (Main Profile - Perfil Principal), ADCP (Advanced Coding Efficiency Profile - Perfil Eficiência de Codificação Avançada), N-Bit, ACPR (Advanced Core Profile - Perfil Cerne Avançado), SSP (Simple Studio Profile - Perfil Estúdio Simples) e CSP (Core Studio Profile - Perfil Estúdio Cerne) (RICHARDSON, 2003). • Escalabilidade O padrão MPEG-4 - Parte 2, assim como o padrão MPEG-2/ITU-T H.262 - Parte 2 admite diferentes perfis com diferentes tipos de escalabilidade. Além das escalabilidades temporal e espacial já definidas pelo padrão MPEG-2 - Parte 2/ITU-T H.262, padrão MPEG-4 - Parte 2 define um novo tipo de escalabilidade: • Escalabilidade Granular Fina Assim como o MPEG-2 - Parte 2/ITU-T H.262, o padrão MPEG-4 - Parte 2 define alguns perfis com suporte a escalabilidade, tais como: SSPr (Simple Scalable Profile - Perfil de Escalabilidade Simples), FGSP (Fine Granular Scalability Profile - Perfil de Escalabilidade Granular Fina), CScP (Core Scalable Profile - Perfil de Escalabilidade Cerne), STP (Scalable Texture Profile - Perfil de Textura Escalável) e ASTP (Advanced Scalable Texture Profile - Perfil de Textura Escalável Avançada) (RICHARDSON, 2003). 2.3.5 Padrão MPEG-4 - Parte 10/ITU-T H264 - AVC O formato de codificação de vídeo híbrido (DPCM /DCT) MPEG-4 - Parte 10/ITU-T H.264, também conhecido por AVC (Advanced Video Coding - Codificação Avançada de 28 Vídeo), publicado inicialmente em 2003 pela norma ISO/IEC 14496-10, foi desenvolvido pelo consórcio JVT (Joint Video Team - Equipe Conjunta de Vídeo) formado por mem- bros do VCEG do ITU e por membros do MPEG da ISO/IEC. Assim como os padrões desenvolvidos anteriormente, o padrão MPEG-4 - Parte 10/ITU-T H.264 - AVC propõe uma alternativa visando o melhor equilíbrio entre eficiência de codificação, complexidade de implementação e custo, baseando-se no estado das tecnologias VLSI (Very Large Scale of Integration - Escala de Integração Muito Elevada) da época de sua concepção. A principal meta do padrão MPEG-4 - Parte 10/ITU-T H.264 - AVC era melhorar a eficiência da codificação do padrão MPEG-2 - Parte 2/ITU-T - H.262 em ao menos 2 vezes, sem aumento significativo no custo final da tecnologia. Similarmente aos padrões de codificação de vídeo anteriores, o padrão MPEG-4 - Parte 10/ITU-T H.264 - AVC ao longo de suas revisões define vários tipos de perfis, onde a seguir são descritos os três perfis base principais (RICHARDSON, 2003): • BP (Baseline Profile - Perfil de Linha Base): Oferece suporte à codificação intra e inter-quadros (utilizando fatias do tipo I e P respectivamente) e codificação de entropia com códigos de comprimento variável de contexto adaptativo (CAVLC - Context-Adaptive Variable Length Codes - Códigos de Comprimento Variável Adaptável ao Contexto). Este perfil é aplicado em vídeo conferência, vídeo telefonia e comunicações sem fio; • MP: Suporta vídeo entrelaçado, codificação inter-quadros utilizando fatias do tipo B, codificação inter-quadros utilizando predição ponderada e codificação aritmética de contexto adaptativo (CABAC - Context-Based Arithmetic Coding - Codificação Aritmética Baseada em Contexto). Este perfil é aplicado em radiodifusão televisiva e armazenamento de vídeo; • EP (Extended Profile - Perfil Estendido): Não suporta vídeo entrelaçado e CABAC, entretanto oferece suporte a métodos de permutação de diferentes fluxos de vídeo codifi- cados e resistência e recuperação de erros aprimorada, sendo utilizado principalmente em aplicações de fluxo de mídias. Um codificador MPEG-4 - Parte 10/ITU-T H.264 - AVC pode utilizar um ou dois de um número de quadros previamente codificados como referência para predição de mo- vimento de cada macrobloco inter-codificado ou partição de macrobloco. Este recurso 29 habilita o codificador a procurar pelo melhor “casamento” da partição de macrobloco cor- rente de um conjunto mais amplo de figuras que apenas o quadro previamente codificado. O codificador e decodificador mantém uma ou duas listas de quadros de referência, contendo quadros que foram previamente codificados e decodificados. Macroblocos inter- codificados e partições de macrobloco em fatias do tipo P são previstas com quadros em uma lista simples: lista 0. Macroblocos inter-codificados e partições de macrobloco em fatias do tipo B podem ser previstas de duas listas: lista 0 e lista 1. Um quadro de vídeo é codificado em uma ou mais fatias, cada uma contendo um número inteiro de macroblocos de 1 a um número total de macroblocos em um quadro. O número de macroblocos por fatia não necessita ser constante dentro de um quadro. Há uma interdependência mínima entre fatias codificadas, o qual pode ajudar a limitar a propagação de erros. Um quadro codificado pode ser composto por diferentes tipos de fatias. Por ex. um quadro codificado com perfil de Linha Base pode conter uma mistura de fatias do tipo I e P e um quadro de perfil Principal ou Estendido pode conter uma mistura de fatias do tipo I, P e B. O MPEG-4 - Parte 10/ITU-T H.264 - AVC define cinco tipos de codificação de fatias: I , P, B , SP (Switching P - P com Chanveamento), SI (Switching I - I com Chaveamento) (RICHARDSON, 2003). Atualmente, o padrão MPEG-4 - Parte 10/ITU-T H.264 - AVC é utilizado por ex., em transmissões dos sistemas de TV terrestre SBTVD e DVB, além de transmissões HDTV de sistemas de TV a cabo e satélite (SBTVD, 2023), (DVB, 2020). • Escalabilidade Em Julho de 2007, foi publicada a nova revisão do padrão MPEG-4 - Parte 10/ITU-T H.264 - AVC (ISO/IEC 14496-10 MPEG-4 - AVC - Anexo G), contemplando o suporte de vídeo escalável. Esta revisão ficou conhecida como SVC (Scalable Video Coding - Codificação de Vídeo Escalável). A partir de então o MPEG-4 - Parte 10/ITU-T H.264 - AVC passa a suportar 3 tipos de escalabilidade, além de combinação destas (Schwarz; Marpe; Wiegand, 2007): 30 • Escalabilidade Temporal • Escalabilidade Espacial • Escalabilidade de Qualidade ou de Relação Sinal/Ruído Suportados através dos seguintes perfis: • SBP (Scalable Baseline Profile - Perfil Linha Base Escalável): Um fluxo de bits de vídeo em conformidade com o SBP contém um fluxo de bits do BL que está em conformidade com uma versão restrita do BP do padrão MPEG-4 - Parte 10/ITU-T H.264 - AVC. Este perfil suporta fatias do tipo B, codificação de entropia do tipo CABAC, embora a BL tenha que estar em conformidade com o BP, que não suporta essas ferramentas. Além disso, as ferramentas de codificação para fontes entrelaçadas não estão inclusas. As escalabilidades temporal e de qualidade são suportadas sem restrição, enquanto a escalabilidade espacial está restrita a taxas de resolução de 1,5 a 2 vezes entre camadas espaciais sucessivas nas direções verticais e horizontais e ao corte alinhado por macroblo- cos. Suas aplicações principais visam aplicativos de videoconferência, dispositivos móveis e de vigilância. • SHP (Scalable High Profile - Perfil Alto Escalável): Um fluxo de bits de vídeo em conformidade com o SHP contém um fluxo de bits vídeo da BL que está em conformidade com o HP do padrão MPEG-4 - Parte 10/ITU-T H.264 - AVC, suportando todas as ferramentas especificadas na extensão SVC. A escalabilidade espacial é suportada sem restrição, isto é, razões de resolução arbi- trárias e parâmetros de corte são suportados, assim como as escalabilidades temporal e de qualidade são suportadas também sem restrições. Suas aplicações principais visam aplicativos de transmissão de vídeo (streaming), vi- deoconferência, dispositivos móveis e de vigilância. • SHIP (Scalable High Intra Profile - Perfil Intra Alto Escalável): Utiliza apenas quadros de atualização de decodificador instantânea (IDR - Instantaneous Decoder Refresh 31 - Refrescamento Instantâneo do Decodificador ). As imagens IDR podem ser decodificadas sem referência aos quadros anteriores. Um fluxo de bits de vídeo em conformidade com o SHIP contém um fluxo de bits de vídeo de BL que está em conformidade com o HP do padrão MPEG-4 - Parte 10/ITU-T - H.264 AVC, sendo permitidas apenas imagens IDR. Todas as ferramentas de escalabilidade são permitidas, como no SHP, mas apenas imagens IDR são permitidas em qualquer camada. Sua aplicação é destinada principalmente a aplicativos de produção, este perfil é res- trito ao SHP a todo uso intra. • SCBP (Scalable Constrained Baseline Profile - Perfil Linha Base Restrito Escalável): Um subconjunto do SBP destinado primariamente a aplicações de comunicação em tempo real. • SCHP (Scalable Constrained High Profile - Perfil Alto Restrito Escalável): Um subconjunto do SHP destinado primariamente a aplicações de comunicação em tempo real. 2.3.6 Padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC O padrão MPEG-H Parte 2/ITU-T H.265, também conhecido por HEVC (High Effi- cient Video Coding - Codificação de Vídeo de Alta Eficiência), publicado inicialmente em 2013 pela norma ISO/IEC 23008 - Parte 2, é um padrão de codificação híbrida DPCM/DCT desenvolvido pelo JCT-VC (Joint Collaborative Team on Video Coding - Equipe Colaborativa Conjunta de Codificação de Vídeo), formado por membros do VCEG do ITU e por membros do MPEG da ISO/IEC. A principal meta inicial do padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC é ofe- recer, em relação ao seu antecessor, o padrão MPEG-4 - Parte 10/ITU-T H.264 - AVC, melhoria na compressão de dados de 25% a 50% com o mesmo nível de qualidade de ima- gem, ou melhoria apreciável na qualidade de imagem considerando-se a mesma taxa de transmissão de vídeo, permitindo compressão de vídeo na taxa de até 1000:1, suportando ainda resolução de vídeo de até UHD 8K (8192×4320). Ao passo que o padrão MPEG-4 - Parte 10/ITU-T H.264 - AVC utiliza a DCT, padrão MPEG-H - Parte 2/ITU-T H.265 32 - HEVC utiliza a DCT, além da DST (Discrete Sine Transform - Transformada Discreta do Seno) (Boyce et al., 2016) e (Sullivan et al., 2013). Para referência, a Tabela 1 exibe a comparação de desempenho de vídeo para a mesma qualidade subjetiva, comparando o MP do padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC com o HP do padrão MPEG-4 - Parte 10/ITU-T H.264 - AVC utilizando uma faixa de resoluções. A redução média da taxa de bits para o o padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC foi de 52% para 480p, 56% para 720p, 62% para 1080p e 64% para UHD 4K. Entre outras características, o padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC se beneficia da utilização de tamanhos maiores de CTU (Coding Tree Unit - Unidade de Árvore de Codificação), substituindo macroblocos de 16 × 16 pixels utilizado em padrões anteriores, por CTUs que podem utilizar estruturas de blocos maiores com amostras de até 64 x 64 pixels e podem subdividir melhor a imagem em estruturas de tamanho variável. O padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC inicialmente divide a imagem em que podem ser de 64 × 64, 32 × 32 ou 16 × 16, com um tamanho de bloco de pixels maior, geralmente aumentando a eficiência da codificação. Tabela 1: Comparação do Desempenho de Vídeo para a Mesma Qualidade Subjetiva Redução média de bitrate comparada com padrão H.264 AVC HP Padrão de Codificação de Vídeo 480p 720p 1080p 2160p HEVC 52% 56% 62% 64% Fonte: (TAN et al., 2014). Além disso, o padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC específica quatro tamanhos de TUs (Transform Unit - Unidade de Transformação) de 4x4, 8x8, 16x16 e 32x32 para codificar o resíduo de predição (diferença entre o quadro predito e o quadro 33 atual). Um CTB (Coding Tree Block - Bloco de Árvore de Codificação) pode ser partici- onado recursivamente em 4 ou mais TUs, que utilizam funções de base inteira baseadas na DCT. Ademais, os blocos de transformação de luma 4 x 4, que pertencem a uma re- gião intra-codificada, são transformados utilizando uma transformação inteira derivada da DST. Este recurso fornece uma redução de 1% na taxa de transmissão de bits de vídeo, mas foi restrito a blocos de transformação luma 4 x 4. O bloco croma utiliza os mesmos tamanhos de TU que o bloco luma, portanto não há transformada 2 x 2 para este bloco (Boyce et al., 2016) e (Sullivan et al., 2013). As ferramentas de processamento paralelo possuem grande importância no processo de codificação. Os ladrilhos (tiles) permitem que a imagem seja dividida em uma grade de regiões retangulares que podem ser codificadas/decodificadas independentemente. O propósito principal dos ladrilhos é permitir o processamento paralelo. As peças podem ser decodificadas independentemente e podem até permitir acesso aleatório a regiões es- pecíficas de uma imagem em um fluxo de vídeo. O WPP (Wavefront Parallel Processing - Processamento Paralelo de Frente de Onda) ocorre quando uma fatia é dividida em linhas de CTUs nas quais a primeira linha é deco- dificada normalmente, mas cada linha adicional requisita que as decisões sejam tomadas na linha anterior. O WPP possui informações de uso do codificador de entropia da linha anterior de CTUs e permite um método de processamento paralelo que pode permitir uma melhor compactação do que os ladrilhos (tiles). Os ladrilhos e WPP são permitidos, entretanto opcionais. Se os ladrilhos estiverem presentes, eles devem ter ao menos 64 pixels de altura e 256 pixels de largura, com um limite de nível específico para o número de blocos permitido. As fatias podem, na maioria das vezes, ser decodificadas independentemente uma da outra, com o propósito principal dos ladrilhos ser o de re-sincronização em caso de perda de dados no fluxo de vídeo. As fatias podem ser definidas como auto-contidas em que a predição não é feita através dos limites das fatias. Entretanto, quando a filtragem em loop é feita em uma imagem, podem ser necessárias informações através dos limites das fatias. As fatias são decodificadas de forma de CTUs, na ordem da varredura retangular e diferentes tipos de codificação podem ser usados para fatias como tipos I, P ou B. Fatias dependentes podem permitir que dados relacionados aos ladrilhos ou WPP 34 sejam acessados mais rapidamente pelo sistema do que se a fatia inteira tivesse que ser decodificada, permitindo a codificação de vídeo com baixo atraso devido à sua menor latência. Em sua primeira versão, o padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC define três tipos de perfis (Boyce et al., 2016) e (Sullivan et al., 2013): • MP: Permite uma profundidade de 8 bits por amostra, com amostragem de croma 4:2:0, que é o tipo de vídeo mais comum utilizado em dispositivos de consumo; • M10P (Main 10 Profile - Perfil Principal 10): Permite uma profundidade de 8 a 10 bits por amostra com amostragem de croma 4:2:0, permitindo melhor qualidade de vídeo, suporte ao espaço de cor conforme ITU-T BT. Rec. 2020 (ITU-R, 2015a), amplamente utilizado em sistemas UHDTV (Ulta High Definition Television Televisão de Definição Ultra Alta). Os decodificadores do padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC em confor- midade com o M10P devem ser capazes de decodificar fluxos de bits feitos com os MP e M10P. Ademais, no M10P o vídeo de 8 bits pode ser codificado com uma profundidade mais alta de 10 bits, permitindo uma eficiência de codificação aprimorada em relação ao MP. • MSPP (Main Still Picture Profile - Perfil de Imagem Estática Principal): Permite que uma única imagem estática seja codificada com as mesmas características do MP. Como um subconjunto do MP, o MSPP permite uma profundidade de 8 bits por amostra com amostragem de croma de 4:2:0. Além dos perfis, o padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC define duas camadas (tiers), criadas para lidar com aplicações que diferem em termos de taxa máxima de bits (Boyce et al., 2016) e (Sullivan et al., 2013): • MT (Main Tier - Camada Principal): Camada projetada para aplicações gerais; • HT (High Tier - Camada Alta): Camada projetada para aplicações de alta perfor- mance. Para que um decodificador esteja em conformidade com um determinado nível/camada, é necessário que seja capaz de decodificar todos os fluxos de bits que são codificados para 35 esse nível/camada e para todos os níveis/camadas inferiores. O padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC é utilizado atualmente pelos sistemas ATSC 3.0, DVB-T2, TV via satélite, TV a cabo e streaming para transmissões em UHD 4K (DVB, 2020) e (ATSC, 2022). • Escalabilidade Em 2014, foi publicada a segunda revisão do padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC (ISO/IEC 23008-2:2014 MPEG-H - HEVC – Anexo H) definindo mais 21 perfis para usos gerais, sendo dois deles para utilização de vídeo escalável. Esta revisão ficou conhecida como SHVC (Scalable High Video Coding - Codificação de Alta Eficiência de Vídeo Escalável). A partir desta revisão, o padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC passa a suportar 5 tipos de escalabilidade, além de combinação destas (Ogura; Espinosa, 2018) e (REGUEIRO et al., 2015): • Escalabilidade Temporal • Escalabilidade Espacial • Escalabilidade de Qualidade ou de Relação Sinal/Ruído • Escalabilidade de Codificador Híbrido • Escalabilidade de Profundidade de Cor • Escalabilidade de Gama de Cores As características de escalabilidade são suportadas pelo padrão MPEG-H - Parte 2/ITU-T - H.265 - SHVC através dos seguintes perfis (Ogura; Espinosa, 2018) e (RE- GUEIRO et al., 2015): • SMP (Scalable Main Profile - Perfil Principal Escalável): Este perfil permite que o BL esteja em conformidade com o MP do padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC. • SM10P (Scalable Main 10 Profile - Perfil Principal 10 Escalável): Este perfil permite que o BL em conformidade com o M10P do padrão MPEG-H - Parte 2/ITU-T H.265 - 36 HEVC. A Tabela 2 mostra um breve comparativo dos recursos de escalabilidade suportados pelo padrão MPEG-4 - Parte 10/ITU-T H.264 - AVC (SVC) e pelo padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC (SHVC), ilustrando os tipos de escalabilidade de vídeo (temporal, espacial etc.) suportados por cada um dos padrões de compressão de vídeo com respectivos exemplos de aplicação. Tabela 2: Comparação dos Recursos de Escalabilidade Suportados pelos Padrões SVC e SHVC Características Padrão Escalável Exemplos Escaláveis SVC SHVC Temporal X X (in HEVC) 30 fps para 60 fps Espacial X X 1080p para 4K x 2K SNR (Qualidade) X X 33 dB para 36 dB Codec Híbrido X BL Codificado em AVC Profundidade de Cor X 8 para 10 bits Gama de Cores X BT.709 para BT.2020 Fonte: (Boyce et al., 2016). 2.3.7 MPEG-I - Parte 3/ITU-T H.266 - VVC O padrão MPEG-I - Parte 3/ ITU-T H.266, sintetizado pela norma ISO/IEC 23090- 3, também conhecido por VVC (Versatile Video Coding - Codificação Versátil de Vídeo), teve sua especificação técnica aceita pelo ITU-T em Agosto de 2020 e sua especificação técnica publicada em Novembro de 2020, é um padrão de codificação híbrida DPCM/DCT desenvolvido pelo JVET, formado por membros do VCEG do ITU e por membros do MPEG da ISO/IEC. Desde o início de sua concepção, o padrão MPEG-I - Parte 3/ ITU-T H.266 - VVC foi projetado não apenas para fornecer uma melhoria na taxa de compressão de vídeo de 30% 37 a 50%, em relação ao seu antecessor (o padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC) com o mesmo nível de qualidade perceptual de imagem, mas também para ser altamente versátil, ou seja, para cobrir todas as necessidades de mídia atuais e emergentes. Isso inclui vídeo além do padrão e de alta definição com SDR (Standard Dynamic Range - Faixa Dinâmica Padrão), incluindo resolução ainda mais alta (até UHD 8K ou maior), HFR (High Frame Rate - Alta Taxa de Quadros), HDR e WCG; gerado por computador ou conteúdo de tela, como ocorre especialmente em compartilhamento de tela e jogos; vídeo 360º para realidade imersiva e aumentada; e aplicativos que exigem atraso ultra baixo, como exibição via rede sem fio e jogos online (Bross et al., 2021). Espera-se uma complexidade de codificação de até dez vezes superior à complexidade do padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC, dependendo da qualidade do al- goritmo de codificação. Ao passo que, espera-se uma complexidade da decodificação de aproximadamente o dobro da complexidade do padrão MPEG-H - Parte 2/ITU-T - H.265 - HEVC (RAO; DOMINGUEZ, 2019), (Bonnineau et al., 2020). O padrão o padrão MPEG-I - Parte 3/ ITU-T H.266 - VVC herdou muito dos projetos de HLS (High Level Syntax - Sintaxe de Nível Alto) do padrão MPEG-4 - Parte 10/ITU- T H.264 - AVC e do padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC, incluindo a estruturação do fluxo de bits em unidades NAL (Network Abstraction Layer - Camada de Abstração de Rede) e o uso de conjuntos de parâmetros em cache com referência indexada. Um objetivo principal do projeto de HLS, que desempenha um papel importante nos sistemas e na interface de transporte para um projeto de codificação de vídeo, é habilitar e expor as funcionalidades de alto nível do projeto, incluindo, por ex., capacidade de acesso aleatório, capacidade de processamento paralelo e escalabilidade de codificação em camadas. Algumas das funcionalidades de HLS do padrão MPEG-I - Parte 3/ ITU-T H.266 - VVC são listadas a seguir (Bross et al., 2021): • RA (Random Access - Acesso Aleatório): A capacidade de acesso aleatório refere-se à habilidade de começar o consumo do conteúdo de vídeo a partir de posições diferentes do início do fluxo de bits. Tal capacidade é necessária para habilitar muitas funciona- lidades fundamentais de aplicativos de vídeo, por ex., buscar ou iniciar a partir de um ponto arbitrário, ingressar em uma transmissão em andamento, alternar para um canal de 38 programa diferente e alternar para um fluxo de bits diferente para adaptar-se a diferentes condições de rede. • RPR (Reference Picture Resampling - Re-amostragem de Imagem de Referência): Convencionalmente, por ex. no padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC, a resolução espacial de um fluxo de bits de vídeo só pode mudar em uma imagem IDR ou equivalente. O padrão MPEG-I - Parte 3/ ITU-T H.266 - VVC também permite que a resolução espacial mude em imagens inter-codificadas através do suporte do recurso RPR. Como o nome RPR implica, quando ocorre tal alteração de resolução, o processo de decodificação de uma imagem pode se referir a uma ou mais imagens de referência anteriores que possuem uma diferente resolução espacial para predição entre imagens e consequentemente, uma re-amostragem das imagens de referência para operação do processo de previsão entre imagens pode ser aplicado. • CTUs, Fatias (Slices), Ladrilhos (Tiles) e Frentes de Onda (Wavefronts): A unidade básica de processamento dentro de uma imagem no padrão MPEG-I - Parte 3/ ITU-T H.266 - VVC, tal como no padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC, é a CTU, que contém as amostras de luminância e crominância de uma região quadrada da imagem (exceto pelo truncamento das CTUs nas bordas direita ou inferior quando a largura ou altura não for divisível pelo tamanho da CTU). No padrão MPEG-I - Parte 3/ ITU-T H.266 - VVC as CTUs podem ser maiores que no padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC, mas o conceito é o mesmo e é semelhante ao conceito de macrobloco no padrão MPEG-4 - Parte 10/ITU-T H.264 - AVC. Similarmente ao padrão MPEG-4 - Parte 10/ITU-T H.264 - AVC e ao padrão MPEG- H - Parte 2/ITU-T H.265 - HEVC, no padrão MPEG-I - Parte 3/ ITU-T H.266 - VVC uma imagem pode ser segmentada em regiões chamadas fatias, cada uma das quais é enviada em sua própria unidade NAL separada. O padrão MPEG-I - Parte 3/ ITU-T H.266 - VVC também herdou dois outros recursos de paralelismo e particionamento de imagem de alto nível do padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC: ladrilhos e frentes de onda. Cada ladrilho é um subconjunto retangular de uma imagem e normalmente não forma uma unidade NAL separada. Quando a ferramenta de frentes de onda é utilizada, a decodificação da próxima linha da CTU pode começar antes que a linha atual tenha sido completamente processada, com o atraso de uma CTU para cada linha subsequente. 39 • Sub-imagem (Subpictures): Uma funcionalidade útil para algumas aplicação e es- pecialmente necessária para vídeo imersivo de alta resolução é o suporte das chamadas operações de BEAM (Bitstream Extraction and Merging - Extração e Mesclagem de Fluxo de Bits). O suporte ao BEAM foi um importante objetivo de projeto no desenvolvimento do padrão MPEG-I - Parte 3/ ITU-T H.266 - VVC HLS. Por ex., em vídeo 360º, em qualquer momento um espectador geralmente vê apenas uma pequena porção espacial de todo o vídeo codificado. Desta forma, para eficiência de transmissão e/ou decodificação, uma grande porção espacial do vídeo codificado pode não precisar ser transmitida e/ou decodificada. Para poder fazer isso de maneira eficiente e conveniente, o fluxo de bits pre- cisa ser codificado de forma que uma região da imagem possa ser extraída e decodificada independentemente sem acessar as outras regiões. • Contornos Virtuais (Virtual Boundaries): Contornos virtuais são contornos dentro de imagens, onde as operações de filtro em loop que seriam aplicadas através dos contornos são desativadas. A granularidade das possíveis localizações dos contornos virtuais é de oito amostras de luminância. Esse recurso serve a dois propósitos: O primeiro é para evitar artefatos de junção introduzidos pela aplicação de filtros em loop em um contorno artificial criado por uma etapa de pré-processamento antes da codificação, por ex., um contorno que pode ocorrer quando um formato de projeção multiface como a projeção cubemap é utilizado para representar um vídeo de 360º durante a codificação. A segunda finalidade dos contornos virtuais é para uso com GDR (Gradual Deco- ding Refresh - Atualização de Decodificação Gradual), quando o contorno entre a região atualizada e a região não atualizada está mudando de imagem para imagem e pode não estar alinhado com os contornos de fatias ou ladrilhos, portanto, uma segunda opção de sinalização de contornos virtual é fornecida para garantir a decodificação sem incompati- bilidade das regiões atualizadas em uma imagem GDR e em suas imagens de recuperação associadas ao acessar aleatoriamente a partir da imagem GDR. Em sua primeira versão, o padrão MPEG-I - Parte 3/ ITU-T H.266 - VVC define seis perfis (Bross et al., 2021): • M10 (Main 10 - Principal 10) e M10 4:4:4 (Main 10 - Principal 10 4:4:4): Estes perfis de codificação de camada única suportam basicamente todas as ferramentas de codificação do padrão MPEG-I - Parte 3/ ITU-T H.266 - VVC (com exceção do modo 40 de paleta, que é suportado no M10 4:4:4 mas não pelo perfil M10) e restrição do fluxo de bits para conter somente uma camada, embora não haja restrição quanto ao uso de escalabilidade de subcamada temporal. • MM10 (Multilayer Main 10 - Multicamada Principal 10) e MM10 4:4:4 (Multilayer Main 10 - Multicamada Principal 10 4:4:4): Perfis de múltiplas camadas com a única diferença comparada aos dois correspondentes perfis de vídeo de camada única, sendo que o fluxo de bits pode conter várias camadas. • M10SP (Main 10 Still Picture - Imagem Estática Principal 10) e M10SP 4:4:4 (Main 10 Still Picture - Imagem Estática Principal 10 4:4:4): Perfis de imagem única com a única diferença em comparação aos dois correspondentes perfis de vídeo de camada única sendo que o fluxo de bits pode conter apenas uma imagem, que precisa ser codificado dentro da imagem. A Figura 11 ilustra uma comparação da qualidade de imagem subjetiva MOS (Mean Opinion Score - Pontuação Média de Opinião) versus o taxa de bits, agrupado a partir das cinco sequências de teste de verificação UHD SDR para os codificadores de referência HM, VTM e VVenC (Bross et al., 2021). Considerando-se, por exemplo, um MOS de valor 5, o codificador VVenC oferece uma compressão de vídeo ligeiramente superior ao do codificador VTM, oferecendo uma taxa de bits de aproximadamente 1,4 Mbits/s, ao passo que o codificador VTM, codifica a mesma qualidade subjetiva de vídeo com taxa de bits de aproximadamente 1,7 Mbits/s. Neste valor de MOS, o codificador HM oferece uma taxa de bits de cerca de 3M bits/s - aproximadamente o dobro da compressão alcançada pelos codificadores VTM e VVenC. O padrão MPEG-I - Parte 3/ ITU-T H.266 - VVC foi adotado como padrão de codificação de vídeo pela nova geração de TV digital terrestre brasileira (TV 3.0) em 2022 (SBTVD, 2024). • Escalabilidade O o padrão MPEG-I - Parte 3/ ITU-T H.266 - VVC suporta diferentes tipos de escalabilidade, tais como (RAO; DOMINGUEZ, 2019), (Bonnineau et al., 2020), (Bross et al., 2021): 41 Figura 11: Comparação da Qualidade de Imagem Subjetiva MOS. Fonte: (Bross et al., 2021). • Escalabilidade Temporal • Escalabilidade Espacial • Escalabilidade de Qualidade ou de Relação Sinal/Ruído • Escalabilidade de Profundidade de Cor • Escalabilidade de Gama de Cores 2.3.8 MPEG-5 - Parte 1 - EVC O padrão de codificação de vídeo MPEG-5 - Parte 1, também conhecido por EVC (Essential Video Coding - Codificação de Vídeo Essencial), publicado em Outubro de 2020, é um padrão de codificação híbrida DPCM/DCT desenvolvido por membros do MPEG da ISO/IEC, tendo suas características sintetizadas pela norma ISO/IEC 23094- 42 1, consistindo em um subconjunto, livre do pagamento de direitos de patente (royalties), ao padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC. Espera-se que o padrão MPEG-5 - Parte 1/EVC torne-se amplamente empregado em uma grande variedade de aplicativos. O documento de requisitos do projeto enfatiza especificamente a importância da codificação em tempo real para a aplicação de streaming para serviços de OTT (Over The Top - Acima do Topo) ao vivo e gravado, assim como, espera-se que outras aplicações, como videoconferência e a radiodifusão tradicional, sejam suportados com eficiência por este novo padrão de codificação de vídeo. Este novo padrão de codificação de vídeo tem como meta oferecer uma melhoria na taxa de compressão de vídeo de 30% a 50%, em relação ao seu antecessor, o padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC, com o mesmo nível de qualidade perceptual de imagem (MCCANN, 2019). Além disso, o padrão MPEG-5 - Parte 1 suportará resoluções de vídeo de (ao menos) UHD 8K (7680x4320) e HFR de ao menos 120 quadros por segundo. A fim de fornecer a mais alta qualidade de imagem possível nos atuais e futuros painéis, o padrão oferecerá suporte a HDR e WCG com precisão de 10 bits. O padrão MPEG-5 - Parte 1/EVC define 2 tipos de perfis (Choi et al., 2020): • BP: Utiliza somente tecnologias antigas o suficiente (com mais de 20 anos) para que não tenham mais problemas de patentes e/ou royalties, selecionadas por considerar alto desempenho de codificação e baixa complexidade. Este perfil suporta uma estrutura de codificação baseada em quad-tree, introduzida em blocos de 64 × 64 a 4 × 4. A predição Intra é a tecnologia usada para explorar a correlação espacial entre vizinhos, suportando os cinco modos de previsão direcional. A predição Inter está sendo utilizada com compensação de movimento uni-bidirecional baseada em bloco. A codificação dos vetor de movimento é baseada no uso de vetor de movimento dos blocos vizinhos como candidatos. A transformada usa a DCT como uma transformação principal para um bloco igual ao tamanho do bloco de codificação, de 64 × 64 a 4 × 4. Após a transformada, uma quantização escalar é aplicada aos coeficientes transformados. O intervalo do parâmetro de quantização é de 0 a 51 e um fator de escala correspondente a cada parâmetro de 43 quantização é definido por uma tabela. Um filtro de loop baseado no padrão H.263 foi empregado para aumentar a qualidade objetiva e subjetiva da imagem. O BP podem ser utilizado em aplicações de vídeo sob demanda ou transmissão ao vivo pela Internet. • MP: Utiliza ferramentas aprimoradas que requerem licença. Cada uma dessas fer- ramentas provê uma melhoria significativa na eficiência da codificação e deve ser capaz de ser desativada de maneira individual. Diferentes ferramentas de codificação são utilizadas por este perfil para aumentar a eficiência da codificação a partir da remoção de redundâncias espaciais, temporais e estatísticas. A principais ferramentas são listadas a seguir: • CBPS (Coding Block-Partitioning Structure - Estrutura de Particionamento de Bloco de Codificação): O MP suporta uma estrutura flexível de particionamento de blocos, utilizando o esquema de mistura de árvores binárias e ternárias. Para melhorar a predição, também é empregada a ordem de codificação da unidade dividida na ordem de varredura de bloco codificado. Uma unidade de árvore de codificação é a unidade básica do esquema de codificação proposto. O tamanho máximo da unidade de árvore de codificação é 128 × 128. Uma unidade de árvore de codificação pode ser particionada ainda mais recursivamente por sua estrutura de árvores binárias e ternárias. • AMVR (Adaptive Motion Vector Resolution - Resolução de Vetor de Movimento Adaptativo): Para reduzir a sobrecarga de bits para sinalizar informações de vetor de movimento, são suportadas várias resoluções do vetor de movimento de 1/4 a 4 pixels (1/4, 1/2, 1, 2 e 4 pixels). O codificador seleciona a resolução com base na decisão de uma otimização de distorção de taxa e o índice de resolução selecionado é sinalizado para o decodificador para cada unidade de codificação quando a informação de diferença do vetor de movimento é sinalizada. • MMVD (Merge with Motion Vector Difference - Mescla com a Diferença do Vetor de Movimento): Provê um novo método de expressão do vetor de movimento com sina- lização simplificada. Semelhante aos modos de ignorar e mesclar no padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC, a mescla com a diferença do vetor de movimento faz uma lista de candidatos a partir de informações de movimento vizinhas, mas pode abran- 44 ger mais movimentos estendidos que não estão limitados aos movimentos vizinhos. Para construir candidatos mais precisos, são utilizados um ponto de partida, uma magnitude do movimento e uma direção do movimento. • AI (Affine Interprediction - Entre Predição Afim): Permite o uso de três modos de movimentos afins: modos de modelo de quatro e seis parâmetros, bem como um modo de mescla de afinação. O campo de movimento afim para uma unidade de codificação é descrito por vetor de movimento de dois pontos de controle localizados nos cantos superior esquerdo e superior direito (modelo de quatro parâmetros) ou vetor de movimento de três pontos de controle localizados nos cantos superior esquerdo, superior direito e inferior esquerdo (modelo de seis parâmetros). Nos modos de ”modelo de quatro e seis parâmetros”, os vetores de movimento do ponto de controle para a unidade de codificação atual são sinalizados no fluxo de bits. Para o ”modo de mesclagem afim”, os vetores de movimento do ponto de controle da unidade de codificação atual são derivados com base nas informações de movimento das unidades de codificação vizinhas. Quando o modo de mesclagem ou pulo é aplicado e ambas largura e a altura da unidade de codificação são maiores ou iguais a 8 pixels, um sinalizador afim no nível da unidade de codificação é sinalizado no fluxo de bits para indicar se o modo de mesclagem afim é usado. Nesse modo, o índice de candidato a mesclagem com um valor máximo de 4 é sinalizado para especificar qual candidato a informações de movimento na lista de candidatos a mesclagem afins é usado para a unidade de codificação. • DSMVR (Decoder-Side Motion Vector Refinement - Refinamento de Vetores de Mo- vimento Adicionais): Este método opera com os dois vetores de movimento da bipredição, que são refinados ainda mais por um processo de correspondência bilateral. No modo de bipredição, vetores de movimento refinados são pesquisados em torno dos vetores de mo- vimento iniciais na lista de imagens de referência L0 e na lista de imagens de referência L1. O processo de pesquisa refinamento de vetores de movimento consiste em uma pes- quisa de deslocamento do vetor de movimento com amostra inteira e refinamento do vetor de movimento com amostra fracionária. A pesquisa do vetor de movimento de amostra inteira calcula a distorção entre os dois blocos de referência candidatos na lista de figuras de referência L0 e L1. A soma das diferenças absolutas entre os blocos de referência com base em cada candidato à vetor de movimento em torno do vetor de movimento inicial é calculado. 45 • HBMVP (History-Based Motion Vector Predictor - Preditor Vetor do Movimento Baseado em Histórico): Para estender o mecanismo preditor de vetor de movimento além da vizinhança espaço-temporal local e permitir o uso de informações de vetor de movi- mento de unidades de codificação remotas, um Vetor de movimento preditor baseado em histórico candidato é utilizado no processo de construção da lista de candidatos mescla- dos. Uma tabela de 23 candidatos a Vetor de movimento preditor baseado em histórico é mantida e atualizada em tempo real. Quando um bloco inter-codificado não afim é deco- dificado, a tabela de Vetor de movimento preditor baseado em histórico é atualizada com as informações de movimento decodificadas na abordagem first-in, first-out; portanto, o candidato a Vetor de movimento preditor baseado em histórico mais antigo é removido da tabela e o Vetor de movimento preditor baseado em histórico mais recente é adicionado ao seu final. Para cada entrada de Vetor de movimento preditor baseado em histórico, um único vetor de movimento e índice de referência para a não-predição ou dois vetores de movimento e dois índices de referência para a bipredição são armazenados. Nenhuma remoção na tabela Vetor de movimento preditor baseado em histórico é aplicada. • ALF (Adaptive Loop Filter - Filtro de Loop Adaptativo): A fim de suprimir artefatos de codificação e melhorar a qualidade visual e objetiva das imagens decodificadas e de referência, as amostras decodificadas são filtradas com um filtro de loop adaptativo. Os parâmetros do filtro de loop adaptativo são sinalizados em unidades independentes da camada de abstração de rede, chamadas de conjunto de parâmetros de adaptação, que podem ser consultadas a partir da fatia ou do bloco de unidade de codificação. Para a filtragem de luminância, são definidos dois tipos de padrões de filtro de diamante (5 × 5 e 7 × 7) e para amostras de crominância, apenas um padrão 5 × 5 é utilizado. Cada estrutura do filtro de loop adaptativo pode consistir em até 25 filtros de luminância diferentes e o filtro de luminância utilizado é selecionado através de um processo de classificação para cada bloco 4 × 4. Para a filtragem de crominância, um único filtro por conjunto de parâmetros de adaptação pode ser sinalizado e usado nos grupos de fatia ou lado a lado. • HTDF (Hadamard Transform-Domain Filter - Filtro no Domínio de Transformada Hadamard): Adicionalmente ao filtro de desbloqueio e ao filtro de loop adaptativo, o filtro de domínio de transformada Hadamard, que visa reduzir os artefatos de toque causados pela quantização de coeficientes residuais é introduzido no padrão MPEG-5 Parte 1 - EVC. O filtro de domínio de transformada Hadamard é aplicado a blocos reconstruídos de 46 luminância quando o parâmetro de quantização é maior que 17. O núcleo da transformada é uma transformada Hadamard 2 × 2, que resulta no filtro de domínio de transformada Hadamard como um filtro de suavização passa-baixa 3 × 3. Os parâmetros do filtro são explicitamente derivados das informações codificadas, incluindo o tamanho do bloco de transformação e o parâmetro de quantização. A ordem do processo de filtragem no padrão MPEG-5 Parte 1 - EVC é o filtro de domínio de transformada Hadamard, desblocagem e filtro de loop adaptativo. • ATS (Adaptive Transform Selection - Seleção de Transformada Adaptável): A se- leção de transformada adaptativa é explorada no MP. Além da DCT tradicional, DST e variantes da DCT podem ser aplicadas para predições intra preditivas e residual inter preditiva. Para um bloco intra-codificado, um sinalizador é utilizado para informar ao decodificador se a seleção de transformada adaptativa é aplicada ou não. Basicamente, o codificador decide sobre o uso da seleção de transformada adaptativa com base no processo de otimização de distorção de taxa no nível da unidade de codificação. Se o codificador selecionar o uso da seleção de transformada adaptativa em uma unidade de codificação como transformação de núcleo, mais dois sinalizadores serão sinalizados para o decodifica- dor para indicar qual tipo é usado, para as direções horizontal e vertical, respectivamente. • ACC (Advanced Coefficient Coding - Codificação Avançada de Coeficientes): Os coeficientes da transformada do bloco codificado (dados residuais) após a quantização são varridos em um padrão de varredura predefinido e a codificados em entropia. Para em- pregar propriedades estatísticas dos coeficientes da transformada, a codificação avançada de coeficiente utiliza a abordagem de codificação do tipo bit-plane. Em particular, os coeficientes transformados são varridos e as coordenadas (x e y) do último coeficiente de transformação diferente de zero na ordem de varredura são sinalizados. O MP do padrão MPEG-5 Parte 1 - EVC pode ser utilizado na transmissão comercial de vídeo UHD 8K, video sob demanda, streaming ao vivo entre outras aplicações. 2.3.9 MPEG-5 - Parte 2 - LCEVC O padrão de codificação de vídeo MPEG-5 - Parte 2, também conhecido por LCEVC (Low Complexity Enhancement Video Coding - Codificação de Vídeo Aprimorada de Baixa Complexidade), publicado em Outubro de 2021, foi desenvolvido por membros do MPEG 47 da ISO/IEC, tendo suas características sintetizadas pela norma ISO/IEC 23094-2, é um padrão agnóstico de aprimoramento de codificação de vídeo que pode ser combinado com outros padrões de compressão vídeo com finalidade de melhorar a eficiência da codificação e processamento, mantendo também a compatibilidade com o ecossistema de dispositivos que utilizam o padrão aprimorado. O padrão MPEG-5 - Parte 2 - LCEVC aproveita ferramentas específicas para codificar ”resíduos”, ou seja, a diferença entre o vídeo original e sua representação compactada. O LCEVC pode melhorar a eficiência da compactação e reduzir a complexidade computacio- nal geral utilizando um pequeno número de ferramentas especializadas de aprimoramento. Ao invés de substituir padrões de codificação de vídeo existentes, o LCEVC foi pro- jetado para alavancar padrões de codificação de vídeo existentes (e futuros) aprimorando sua performance enquanto reduz sua complexidade computacional. Não significa ser uma alternativa para outros padrões de codificação de vídeo, mas um complemento útil para qualquer padrão. Este objetivo é alcançado através da combinação do processamento de um vídeo de entrada em uma resolução mais baixa com um padrão de vídeo com camada simples e utilizando um conjunto simples e pequeno de ferramentas altamente especializadas para corrigir deficiências, upscale e adicionar detalhes ao vídeo processado (Battista et al., 2022). 2.4 Considerações Finais Neste capítulo apresentou-se o estado da arte dos padrões híbridos (DPCM/DCT) de codificação de vídeo, apresentando desde o primeiro padrão híbrido de codificação de vídeo desenvolvido, o padrão ITU-T - H.261, até os padrões de codificação de vídeo híbridos mais modernos, como o padrão comercialmente maduro MPEG-H - Parte 2/ITU-T H.265 - HEVC e os padrões recém normatizados como o padrão MPEG-I - Parte 3/ ITU-T H.266 - VVC, MPEG-5 - Parte 1 EVC e MPEG-5 - Parte 2 LCEVC. Um padrão de codificação de vídeo é considerado híbrido por empregar diferentes ferramentas para remoção de redundâncias espaciais e temporais, tais como: codificação de entropia, DPCM, predição por compensação de movimento e codificação por transfor- 48 mada. As normas dos padrões de codificação de vídeo não especificam detalhadamente a estrutura do codificador e/ou decodificador, apenas definem sintaxes do fluxo de dados e as ações a serem tomadas de acordo com a recepção de dados, deixando para o implementador realizá-la de maneira mais conveniente aos propósitos desejados. A linha do tempo apresentada na Figura 4 ilustra de forma resumida a história dos padrões híbridos de codificação de vídeo, apresentando os marcos temporais de lançamento ou previsão de lançamento desde o padrão ITU-T - H.261 até o padrão MPEG-5 - Parte 2 LCEVC, assim como as principais características dos padrões de codificação de vídeo apresentados neste capítulo. No capítulo seguinte (Capítulo 3) serão apresentados conceitos de multiplexação de A/V e dados digitais, bem como o estado da arte dos formatos contêineres utilizados pelos atuais sistemas de TV digital. 49 3 CAMADA DE TRANSPORTE Neste capítulo são apresentados conceitos de multiplexação de áudio, vídeo e dados digitais, o surgimento de formatos contêineres para transporte destes elementos, bem como o estado da arte dos formatos contêineres definidos pela ISO/IEC e utilizados pelos atuais sistemas de TV digital: MPEG-2 - Parte 1 - TS (Transport Stream - Fluxo de Transporte), MPEG-4 - Parte 12 - ISO BMFF (Base Media File Format - Formato de Arquivo de Mídia Base), MPEG-H - Parte 1 - MMT (MPEG Multimedia Transport - Transporte Multimídia MPEG), bem como o formato contêiner definido pelo sistema ATSC 3.0, o ROUTE/DASH. 3.1 Introdução O surgimento dos variados padrões de codificação de áudio e vídeo digitais vem acom- panhado do advento de formatos contêineres distintos. Um formato contêiner é responsável pelo encapsulamento, armazenamento, trans- porte, sincronismo, multiplexação e identificação dos conteúdos codificados de áudio e vídeo digitais, subtítulos, aplicativos interativos e dados em geral. Um bitstream multimídia deve ser particionado e empacotado em várias porções ou blocos do contêiner. O particionamento em pequenos pedaços facilita a recuperação de informações em caso de corrupção ou perda de pacotes, além de facilitar acesso aleatório ao conteúdo empacotado. Um bloco geralmente é formado por até três partes: • Cabeçalho • Dados ou carga • Correção de erros O cabeçalho deve conter informações que permitem identificar o início do pacote, conteúdo transportado, sincronismo entre outras. Dados, carga ou payload transportam o conteúdo fragmentado de áudio e vídeo codi- ficado, além de dados. 50 Correção de erros se destina a detectar e corrigir erros ocorridos no transporte dos pacotes. Alguns tipos de contêiner mais simples podem conter diferentes tipos de formatos de áudio, enquanto formatos contêiner mais avançadas podem suportar diferentes formatos de áudio e fluxos de vídeo. Alguns formatos são mais apropriados para utilização na radiodifusão do sinal de TV digital, outros para transporte de conteúdo multimídia através da Internet, ou ainda mais indicado para serem utilizados em serviços de streaming, assim como há formatos contêineres mais apropriados para utilização em mídias ópticas. Diferentes tipos de contêiner surgiram ao longo do tempo com as variadas limitações e premissas, sendo alguns deles enumerados nas seções a seguir. 3.2 Formatos Contêineres ISO/IEC 3.2.1 MPEG-2 - Parte 1 - TS (Transport Stream - Fluxo de Transporte) O formato contêiner TS, sintetizado pela norma MPEG-2 - Parte 1 ISO/IEC 13818-1, é um protocolo de comunicação para áudio, vídeo e dados definidos na norma MPEG-2. O padrão MPEG-2 define a sintaxe do fluxo de bits e os métodos necessários para receber e de-multiplexar vídeo e áudio codificados sincronizados no tempo, informações de controle PSI (Program Specific Information - Informação Específica do Programa) e dados privados. O processo de intercalar pacotes TS de mais de um programa em um bitstream uni- ficado, mantendo-se o sincronismo temporal de cada programa contido neste fluxo é co- nhecido como multiplexação. Assim como ocorre na norma MPEG-1, o fluxo contínuo de áudio ou vídeo codificado em ES (Elementary Stream - Fluxo Elementar) é fragmentado e empacotado em pacotes independentes e com tamanho variável, formando um PES. Por sua vez, os PESs são segmentados em pacotes TS de tamanho fixo a fim de facilitar transmissão em tempo real (Lechner et al., 2006). 51 Um MPEG-2 TS é uma série continua de pacotes TS, onde cada pacote possui ta- manho fixo de 188 bytes. Este tamanho foi originalmente escolhido a fim de manter-se a compatibilidade com os sistemas ATM (Asynchronous Transfer Mode - Modo Assíncrono de Transferência). O TS destina-se à transmissão de dados por meios, onde a perda de dados é provável e tende a ser transmitido com taxa de bits constante CBR (Constant Bitrate - Taxa de Bits Constante) e preenchido com bytes de preenchimento quando não há dados suficientes. O cabeçalho ou header é composto de 4 bytes e sempre inicia-se com o byte de valor 0x47 para fins de sincronismo. Os 184 bytes restantes são utilizados para transmissão de dados ou payload do pacote TS. O campo denominado PID (Packet Identifier - Identificador de Pacote), contido no cabeçalho de cada pacote TS, é peça fundamental para selecionar os componentes ou elementos no TS. O PID é utilizado para localizar pacotes TS de um fluxo de componente específico na multiplexação do serviço, a fim de facilitar a reconstrução da carga útil de cada pacote TS em seus níveis mais elevados, isto é, pacotes TS em PES e em ES. Uma série de pacotes TS contendo o mesmo PID inclui um único elemento do programa, por ex., um ES de vídeo ou informações descritivas sobre um ou mais elementos do programa, por ex., uma tabela PSI (Program Specific Information - Informação Específica do Programa). O padrão MPEG-2 define tabelas que fornecem informações necessárias para atuar ou descrever melhor os fluxos essenciais de dados dentro da multiplexação do serviço. As tabelas lógicas são construídas usando uma ou mais seções. Essas tabelas são chamadas coletivamente de PSI. As tabelas PSI provêm os dados necessários para localizar programas específicos ou elementos na multiplexação do serviço. Cinco tabelas PSI são definidas: PAT (Program Association Table - Tabela de Associação de Programa) - PID (0x00) - responsável listar todos os programas disponíveis no TS; PMT (Program Map Table Tabela de Mapeamento de Programa) - responsável por listar as informações contidas em um determinado pro- grama; CAT (Conditional Access Table - Tabela de Acesso Condicional) - PID (0x01) responsável pelo gerenciamento das chaves de criptografia utilizadas em acesso condici- onado; NIT (Network Information Table - Tabela de Informação de Rede) - responsável por agrupar identificadores de fluxo de transporte em uma rede, fornecendo parâmetros 52 de acesso e outros detalhes; TSDT (Transport Stream Description Table - Tabela de Des- crição de Fluxo de Transporte) - responsável por armazenar descritores relacionados ao TS em geral. Valores fixos de PID são atribuídos a algumas tabelas PSI, como a PAT, entretanto a PMT não possui valor fixo de PID. A PAT é a tabela inicial para PSI. Se não utilizasse um valor fixo e conhecido de PID, a ”sintonia”(análise do fluxo) levaria mais tempo e a aquisição do canal seria mais lenta. O motivo pelo qual a PMT não possui valor fixo de PID é que a análise do fluxo é hierárquica. Uma única PAT pode apontar para muitas seções do mapa do programa e o número de seções do mapa do programa depende do uso específico. Ademais, o padrão MPEG-2 provê um mecanismo para adicionar tabelas, fora do escopo original do padrão. Os PESs carregam informações de sincronia de fluxo no cabeçalho do PES utilizando campos DTS (Decoding Time Stamp - Selo Temporal de Decodificação) e PTS (Presen- tation Timestamp - Selo Temporal de Apresentação). Os timestamps habilitam a decodi- ficação das unidades de acesso na ordem correta e apresentam as unidades de acesso no tempo relativo correto, isto é, na taxa correta, respectivamente. O DTS e o PTS têm 33 bits de comprimento com unidades de relógio de 90 kHz. O padrão MPEG-2 descreve um método para sinalizar a sincronia entre unidades de acesso em vários fluxos elementares. O codificador anexa um PTS aos quadros de vídeo e às estruturas de áudio (unidades de apresentação de áudio). Fundamentalmente, o PTS informa ao receptor em qual momento exibir uma imagem ou emitir uma amostra de áudio. De acordo com o padrão MPEG-2, os DTSs são opcionais e portanto nem sempre implementados no receptor. Um receptor pode assumir o tempo do DTS com base na necessidade de satisfazer o PTS correspondente para a mesma unidade de acesso. Isso é facilmente alcançado, dado que a prática corrente de codificação é transmitir as unidades de acesso de vídeo na ordem em que elas serão decodificadas. De maneira similar, um receptor também pode assumir o tempo de PTS para um quadro que não contém expli- citamente um PTS, conhecendo a taxa de quadros, o PCR (Program Clock Reference - 53 Referência do Relógio do Programa) e o tempo do PTS anterior (Lechner et al., 2006). Este formato contêiner é utilizado, por ex. em nos sistemas de TV digital terrestre ATSC 1.0 (ATSC, 2022), DVB-T/T2 (DVB, 2020) e ISDB-T (ISDB-T, 2020). 3.2.2 MPEG-4 - Parte 12 - ISO BMFF (Base Media File Format - Formato de Arquivo de Mídia Base) O formato contêiner ISO BMFF, sintetizado pela norma MPEG-4 - Parte 12 ISO/IEC 14496-12, define uma estrutura geral para arquivos multimídia baseado no tempo, como áudio e vídeo, possuindo texto idêntico à norma ISO/IEC 15444-12 (JPEG 2000 - Parte 12). O contêiner ISO BMFF foi padronizado para troca de dados multimídia e download progressivo de aplicações. Sendo desenvolvido como um formato flexível e extensível que facilita o intercâmbio, gerenciamento, edição e apresentação da mídia. A apresentação pode ser local, via rede, ou outro através de outro mecanismo de entrega. O formato do arquivo foi projetado para ser independente de qualquer protocolo de rede em particular, habilitando o suporte a eles em geral. É utilizado como base para outros formatos de arquivo de mídia, por ex., o formato de contêineres MP4. Arquivos em conformidade com o formato ISO BMFF são formados como uma série de objetos, chamados caixas ou boxes. Todo dado está contido nas caixas e não há outro dado no arquivo. Isso inclui qualquer assinatura inicial requerida pelo formato de arquivo específico. A caixa é um bloco de construção orientado ao objeto definido por um identificador de tipo e comprimento únicos, sendo chamada de átomo em algumas especificações. O formato ISO BMFF contém o temporização, estrutura e as informações de mídia para sequências programadas de dados de mídia, como apresentações audiovisuais. A estrutura do arquivo é orientada a objetos. Um arquivo pode ser decomposto em objetos básicos de maneira muito simples e a estrutura dos objetos é implícita em seu tipo. Um vídeo pode estar contido em vários arquivos. A capacidade de dividir um filme em pedaços menores – chamados fragmentos, segmentos ou pedaços – é fundamental em aplicativos de streaming, pois permite-se que o decodificador comece a decodificar a mídia 54 sem a necessidade de ter completado seu download. Todas as informações de tempo e enquadramento devem estar no arquivo ISO BMFF e os arquivos auxiliares podem essencialmente usar qualquer formato. Eles devem ser capazes somente de descrever utilizando metadados definidos neste formato contêiner. A fim de identificar as especificações às quais um arquivo ISO BMFF está em confor- midade, marcações são utilizadas como identificadores no formato do arquivo. Elas são definidas em uma caixa denominada FTYP (File Type Box - Caixa de Tipo de Arquivo), que deve ser inserida no início do arquivo. Um segmento de inicialização é definido como um FTYP seguido por um MOOV (Movie Header Box - Caixa de Cabeçalho de Filme), ao passo que um segmento de mídia ISO BMFF é definido como um segmento opcional do tipo STYP (Segment Type Box - Caixa de Tipo de Segmento) seguido por segmento SIDX (Segment Index Box - Caixa de Índice de Segmento), MOOF (Movie Fragment Box - Caixa de Fragmento de Filme), seguido por uma ou mais MDAT (Media Data Box - Caixa de Dados de Mídia). Se o STYP não estiver presente, o segmento deverá estar em conformidade com as marcações listadas no FTYP, no segmento de inicialização. Caixas de alto nível válidas definidas originalmente pelo formato contêiner ISO BMFF, exceto FTYP, MOOV, STYP, MOOF e MDAT, podem aparecer entre o final de um segmento de inicialização ou segmento de mídia e antes do início de um novo segmento de mídia. Essas caixas devem ser aceitas e ignoradas pelo agente do usuário e não são consideradas parte do segmento de mídia especificado neste formato contêiner. Uma marcação pode indicar o tipo de codificação utilizada, como os dados de cada codificação são armazenados, restrições e extensões aplicadas ao arquivo, compatibilidade ou o uso pretendido do arquivo. FTYP contém dois tipos de marcações. O primeiro tipo é o major_brand que identifica a especificação do melhor uso para o arquivo. É seguida pela minor_version, um número inteiro informativo de 4 bytes para a versão secundária da marcação principal. O segundo tipo de marcação é o compatible_brands, que identifica múltiplas especificações às quais o arquivo está em conformidade. Todos os arquivos devem conter uma caixa de tipo de arquivo, mas por motivos de compatibilidade com uma versão anterior da especificação, 55 os arquivos podem estar em conformidade com o ISO BMFF e não conter uma caixa de tipo de arquivo. Nesse caso, eles devem ser lidos como se contivessem um FTYP com a marcação principal (PARK; LIM; SUH, 2016). Se os segmentos forem armazenados em arquivos separados (por ex., em um servidor HTTP (Hypertext Transfer Protocol - Protocolo de Transferência de Hipertexto) padrão), recomenda-se que estes ’arquivos de segmento’ contenham uma caixa de tipo de segmento, que se estiver presente, deve ser a primeira, a fim de permitir a identificação destes arquivos e a declaração das especificações com os quais estão em conformidade. Um tipo de segmento tem o mesmo formato de uma caixa FTYP, exceto pelo fato de receber a caixa tipo STYP. As marcas contidas nela podem incluir as mesmas marcas incluídas na caixa FTYP que precedeu a caixa MOOV e podem também incluir marcas adicionais para indicar a compatibilidade deste segmento com diversas especificações. As caixas de tipo de segmento válidas devem ser a primeira caixa de um segmento. As caixas de tipo de segmento podem ser removidas se os segmentos forem concatenados (por ex., para formar um arquivo completo), mas o que não é obrigatório. As caixas de tipo de segmento que não estão em primeiro lugar em seus arquivos podem ser ignoradas (MPEG, 2022). A caixa SIDX fornece um índice compacto de um fluxo de mídia dentro do segmento de mídia ao qual se aplica. Foi projetada para poder ser usado não somente com om formatos de mídia baseadas no formato ISO BMFF, mas também com outros formatos de mídia, como por ex., MPEG-2 TS. Um sub-segmento é definido como um intervalo de tempo do (sub)segmento que o contém e corresponde a um único intervalo de bytes do (sub)segmento que o contém. As durações de todos os sub-segmentos somam-se à duração do (sub)segmento que contém. Cada caixa SIDX fornece informações sobre um único fluxo de mídia do segmento, conhecido como fluxo de referência. Se fornecida, a primeira caixa SIDX em um segmento, para um determinado fluxo de mídia, documentará a totalidade desse fluxo de mídia no segmento e precederá qualquer outra caixa SIDX no segmento do mesmo fluxo de mídia. Este formato contêiner é utilizado, por ex., em serviços de streaming baseado no padrão MPEG-DASH como o Netflix. 56 3.2.3 MPEG-H - Parte 1 - MMT (MPEG Multimedia Transport - Transporte Multimídia MPEG) O formato contêiner MPEG-2 - Parte 1 - TS foi adotado por diferentes sistemas de TV digital para entrega de conteúdo de devido às suas características e pressupostos. Dentre estes, está o atraso constante no enlace de entrega, o que é apropriado para sistemas típicos de TV terrestres ou satélite dado que comumente possuem enlaces com linha de visada ou próximo a este requisito (WALKER et al., 2016). Além disso, O formato MPEG-2 - Parte 1 - TS fornece mecanismos muito eficientes para multiplexação de múltiplos fluxos de dados audiovisuais em um único fluxo de entrega de acordo com a ordem de consumo, dado a suposição de que o fluxo multiplexado deve ser entregue e reproduzido em ordem sequencial. Esses princípios fizeram do formato MPEG-2 - Parte 1 - TS uma boa solução para stre- aming de conteúdo multimídia, caso um grande número de usuários consuma exatamente o mesmo conteúdo. Entretanto, o advento do ambiente híbrido (Internet e radiodifusão) de entrega de conteúdo multimídia, aumentando o consumo de conteúdo multimídia personalizado pela Internet introduziu um novo requisito para acesso mais individualizado e flexível ao con- teúdo, oferecendo novos desafios ao formato MPEG-2 - TS. Por ex., o anúncio personali- zado ou a seleção do fluxo de áudio com um idioma adequado para um usuário específico não podem ser eficientemente suportados pelo formato MPEG-2 - TS, uma vez que a in- serção ou multiplexação dinâmica de anúncios ou fluxos de áudio requer demultiplexação e re-multiplexação de fluxos multiplexados (PARK; LIM; SUH, 2016). O formato contêiner MPEG-4 - Parte 12 - ISO BMFF, padronizado para intercâmbio de dados multimídia e download progressivo de aplicativos, enfrenta um desafio simi- lar, dado que armazena metadados contendo informações para reprodução sincronizada que são armazenadas separadamente dos dados da mídia compactada. Para suportar o download progressivo do arquivo, isto é, permitir a reprodução do arquivo antes de ser completamente baixado, os metadados podem ser intercalados com os dados de mídia na ordem de consumo. Entretanto, é difícil acessar eficientemente um determinado subcon- junto do arquivo, por ex., baixar apenas um fluxo de áudio com idioma específico para 57 alternar de um fluxo para outro durante a reprodução. Em reconhecimento aos novos desafios lançados aos formatos contêineres existentes até então, o consócio MPEG desenvolveu novos padrões com o intuito de atender aos novos requisitos de entrega de conteúdo multimídia pela Internet. Primeiramente, foi desenvolvido o padrão MPEG-DASH, com foco na entrega de streaming adaptativo de conteúdo multimídia utilizando o ambiente legado HTTP (PARK; LIM; SUH, 2016). A partir da conclusão do padrão MPEG-DASH, o consórcio começou a abordar os novos desafios da entrega de conteúdo multimídia em ambientes de Internet além do HTTP. Desta maneira foi concebido o formato contêiner MMT, sintetizado pela norma MPEG- H - Parte 1 ISO/IEC 23008-1, destinando-se ao transporte de informações multimídia através da Internet. O formato contêiner MMT assume redes IP (Internet Protocol - Protocolo de Inter- net) com caches inteligentes de rede próximos às entidades receptoras, que não apenas ativamente armazenam em cache o conteúdo, mas também adaptativamente empacotam e enviam o conteúdo para as entidades receptoras. Este formato contêiner também assume um ambiente de rede no qual o conteúdo pode ser acessado com uma granularidade mais fina, com nomes identificáveis únicos, ao invés de sua localização e pequenos trechos do conteúdo sendo armazenados em cache próximo à entidade receptora, independentemente dos provedores de serviços específicos e de sua localização (PARK; LIM; SUH, 2016). O formato contêiner MMT especifica além do formato contêiner, um protocolo de en- trega, um conjunto de mensagens de sinalização e um método que descreve as informações de apresentação para a entrega de serviços multimídia em redes baseadas em pacotes. A MMT assume que as entidades sejam sincronizadas com o UTC (Coordinated Universal Time - Tempo Universal Coordenado) para suportar entrega eficaz de conteúdos multi- mídia no ambiente de entrega híbrido emergente. Estas especificações são agrupadas pelo padrão MMT em três grandes áreas funcionais: 58 • Área Funcional MPU • Área Funcional de Entrega • Área Funcional de Sinalização As especificações definidas pelo formato contêiner MMT podem ser usadas em am- bientes de rede IP e de maneira mais geral, em redes de entrega baseadas em pacotes. Várias características das quais, ambientes de entrega foram levados em consideração, tais como, atraso de entrega de pacotes ponta a ponta variável no tempo das entidades de envio para as entidades de recepção e os meios para distinguir mensagens de sinalização fornecidas pela rede subjacente dos dados de mídia. As soluções de cada área funcional podem ser utilizadas independentemente de acordo com as necessidades da aplicação. A área funcional MPU (Media Processing Unit - Unidade Média de Processamento) define um modelo lógico e seu formato de encapsulamento associado para mídia tempo- rizada e não-temporizada, utilizando o formato contêiner ISO BMFF. O formato MPU inclui uma estrutura de encapsulamento auto-contida que permite consumo independente de dados de mídia. Ele oculta detalhes específicos do código da preparação da entrega, incluindo armazenamento em cache no nó da rede intermediário ou transporte direto como carga útil dos protocolos de entrega. Também definindo um método de associação de conteúdo encapsulado com o formato definido para apresentação utilizando linguagem HTML5 (HyperText Markup Language - Linguagem de Marcação de Hipertexto5) e um método para sincronizar a apresentação entre conteúdos temporizada e não-temporizada. A área funcional de entrega formato contêiner MMT define um formato de carga útil independente dos tipos de mídia e codificadores, que permite a fragmentação e agrega- ção do conteúdo encapsulado como MPUs para entrega usando protocolos baseados em pacotes. Também especifica um protocolo da camada de aplicação e mecanismos de qua- lidade de serviço associados por meio de ambientes de rede heterogêneos, que permitem multiplexação, entrega confiável de conteúdo de mídia e comunicação entre camadas para maximizar a qualidade do serviço e a qualidade da experiência do usuário. A área funcional de sinalização do formato contêiner MMT define o formato de um conjunto de mensagens para gerenciar o consumo e a entrega de MPUs. As mensagens de gerenciamento de consumo são utilizadas para sinalizar a estrutura do conteúdo com local 59 específico, enquanto as mensagens de gerenciamento de entrega são usadas para sinalizar a estrutura das cargas úteis e configuração do protocolo (PARK; LIM; SUH, 2016). O formato contêiner MMT além de suportar a entrega híbrida de serviços, onde os serviços são entregues por meio de rede de transmissão dedicada e da rede baseada em IP (rede de banda larga), suporta serviços que incorporam dispositivos complementares que podem receber componentes multimídia através do dispositivo principal ou através do outras redes que não a rede de transmissão. Sendo também projetado para entregar e processar dados multimídia não apenas como um fluxo de bits, mas como uma série de blocos de mídia auto contidos, subconjuntos tem- porais não sobrepostos de conteúdo de mídia na ordem do tempo de apresentação. Cada pedaço contém uma série contínua de unidades de acesso ao conteúdo de mídia, para que os componentes de multimídia possam ser facilmente combinados ou substituídos nos limites dos blocos, em vez de emendas de fluxos de bits complexos. Além disso, cada bloco tem sua própria informação de tempo confinada dentro do pedaço e a sincroniza- ção de componentes multimídia pode ser representada por pedaço, o que permite que as informações de sincronismo sejam representadas sem requerer a atribuição de tempo de apresentação específico para cada unidade de acesso para serviços personalizados ou servi- ços localizados antes da entrega, além de permitir a modificação do tempo de apresentação de cada unidade de acesso quando componentes de mídia são compostos ou substituídos dinamicamente no lado do cliente simplesmente atribuindo o tempo de apresentação da primeira unidade de acesso em um bloco, ao invés de modificar as sinalizações de data e hora de apresentação de cada unidade de acesso. O protocolo MMT foi concebido para oferecer suporte ao transporte de identifica- dores exclusivos globalmente para cada bloco. Com esse recurso, a descrição do serviço pode se referir a um componente multimídia por seu nome, em vez de sua localização ou informações atribuídas. Ao passo que outros formatos contêiner permitem a reutilização da mesma identificação nos diferentes programas, o formato contêiner MMT permite as- sociar um identificador globalmente exclusivo para referenciar cada componente, o que permite que o conteúdo empacotado tenha componentes fisicamente armazenados em di- ferentes dispositivos. Por ex., um conteúdo empacotado pode incluir vários componentes consultando seus identificadores exclusivos globalmente e eles podem ser identificados por 60 outros sistemas, resolvendo a localização mais próxima ou caminho dos componentes de mídia física quando o serviço específico é instanciado. Este aspecto permitirá a separação do provisionamento e a entrega de serviços, para permitir a entrega eficiente de dados em serviços sob demanda, reduzindo várias entregas dos mesmos dados de mídia. No formato contêiner MMT, as informações de tempo de entrega e apresentação são separadas. A MPU está associada apenas às informações de tempo de apresentação. A versão empacotada da MPU transportada pelo protocolo MMT está associada a informa- ções de tempo de entrega. Além disso, a sincronização da apresentação é fornecida pelas mensagens de sinalização do formato contêiner MMT. A MPU representa as informações de tempo de apresentação de cada (AU - Access Unit - Unidade de Acesso) em relação ao início de cada MPU, permitindo a inserção dinâmica ou multiplexação de componentes sem interromper a continuidade da apresentação. O formato contêiner MMT também pode prover a apresentação sincronizada entre vários clientes pelos clientes, utilizando a sincronização das MPUs em relação à temporização UTC. Os pacotes do protocolo MMT carregam uma instância de tempo de entrega, uma vez que os ambientes de entrega IP sofrem com instabilidade de atraso. O protocolo MMT fornece um mecanismo para absorver a instabilidade de atraso para a reprodução sem nenhum estouro. O protocolo MMT pressupõe que a sincronização baseada em UTC nos dispositivos e pacotes de entrega tenha noção exata da instância do tempo de entrega do remetente, para que os receptores possam recuperar corretamente o atraso entre os pacotes. Além disso, O protocolo MMT define o modelo de buffer hipotético do receptor para a entidade emissora determinar o atraso de buffer necessário e o tamanho do buffer necessário, enquanto garante uma recuperação perfeita dos atrasos entre os pacotes do protocolo MMT introduzidos pelas entidades remetentes. Um pacote do protocolo MMT carrega um identificador de pacote (packet_id) para suportar a multiplexação no nível de pacote de vários MMT ativos, uma série de MPUs consumidas por um único decodificador de mídia, em um único fluxo de pacotes MMT. Ele fornece vários tipos de dados na ordem de consumo no destinatário para ajudar na sincronização entre diferentes tipos de dados de mídia sem introduzir grandes atrasos. O pacote MMT também suporta a multiplexação de dados de mídia e mensagens de sinalização em um único fluxo de pacotes. Um packet_id identifica exclusivamente uma 61 série de MPUs associadas a um identificador exclusivo global dentro de uma sessão MMT. O pacote MMT contém dois tipos de número de sequência: packet_counter e packet_- sequence_number. packet_counter representa a sequência de pacotes, independentemente do valor de packet_id, permitindo a detecção imediata de pacotes perdidos. Por outro lado, packet_sequence_number é o número de sequência específico para cada packet_id, incrementado individualmente para cada packet_id. O packet_sequence_number permite a substituição de pacotes contendo um MPU por outro durante a entrega sem afetar a integridade do fluxo de pacotes MMT (PARK; LIM; SUH, 2016). Conforme ilustrado na Figura 12, um pacote MMT é uma entidade lógica que agrega dados de mídia codificados sobre o conteúdo, ou seja, ativos MMT e as informações para o processamento da camada de entrega, como CI (Composition Information - Informação de Composição) e ADC (Asset Delivery Characteristic - Características de Entrega de Ativo). Um pacote MMT carrega uma CI e uma ou mais ADCs. Figura 12: Estrutura Lógica de um Pacote MMT. Fonte: Adaptado de (PARK; LIM; SUH, 2016). Um ativo MMT define a estrutura lógica que transporta dados de mídia codifica- dos. Ao contrário dos fluxos elementares convencionalmente usados nos padrões MPEG projetados para transportar principalmente dados cronometrados, um ativo MMT foi pro- jetado para transportar uniformemente dados cronometrados e não cronometrados. Os dados cronometrados são dados de mídia audiovisual que requerem decodificação e apre- sentação sincronizadas de uma unidade de dados específica em um momento designado, 62 enquanto os dados não cronometrados podem ser decodificados e apresentados em um momento arbitrário com base no contexto do serviço ou acionados pela interação com o usuário. Os ativos MMT coletivamente se referem a um MPU com a mesma identificação (ID). Qualquer tipo de dado que pode ser consumido individualmente pela entidade diretamente conectada ao cliente MMT é considerado um ativo MMT separado. Isso inclui não apenas dados de mídia codificados decodificáveis por um único padrão de mídia, mas também outros tipos de dados que já foram multiplexados. Tipos de dados de exemplo que podem ser considerados como ativos MMT individuais são MPEG-2 TS, arquivo MP4 e arquivo JPEG. A CI (Composition Information - Informação de Composição) MMT especifica a relação espacial e temporal entre os ativos MMT, o que também podem ser útil para determinar a ordem de entrega dos ativos MMT. Ela também fornece informações para associar ativos a uma tela específica para ambientes de apresentação de várias telas. Essas informações também podem ser usadas para determinar a configuração de entrega em ambientes de entrega heterogêneos. As ADC (Asset Delivery Characteristic - Características de Entrega de Ativo) de ativos MMT fornecem informações de QoS (Quality of Service - Qualidade de Serviço) necessárias para a transmissão de ativos MMT. A entidade que entrega fluxos de pacotes contendo um pacote MMT para configurar parâmetros pode utilizar essas informações. A entidade da camada de entrega subjacente também pode usá-lo para agendar a entrega multiplexada de ativos MMT (Lim et al., 2013). Este formato contêiner é um dos formatos contêineres utilizados no sistema de TV digital terrestre ATSC 3.0 (ATSC, 2022) e oferece suporte, por ex., a novos e diferentes tipos de serviços, como os híbridos e multi-tela (PARK; LIM; SUH, 2016): • Serviços híbridos: o conteúdo pode ser agregado e combinado a partir de uma variedade de fontes e entregues através de comutação dinâmica entre canal de TV terrestre e Internet banda larga; • Multi-tela: Múltiplas visualizações associadas ao mesmo programa, exibido em uma única ou em várias telas, através das quais o usuário pode visualizar diferentes aspectos 63 do mesmo programa ou informações relacionadas aos aspectos do programa. 3.3 Formatos Contêineres ATSC 3.0 3.3.1 ROUTE/DASH Uma inovação importante do formato contêiner MPEG-2 TS foi o uso de pacote transporte, com estrutura de 188 bytes, o que permitiu a distribuição de vários fluxos de mídia em um fluxo comum. Sua operação é baseada em alguns pressupostos básicos, como o atraso constante através do link de entrega e a criptografia do fluxo de pacotes. O fluxos de pacotes individuais em geral carregam um ou mais fluxos de mídia relacionados. Os fluxos podem ser criptografados em um pacote base para fornecer acesso condicional. Além disso, conforme as conexões de banda larga se tornaram amplamente disponíveis o uso da Internet para serviços de streaming tornou-se cada vez mais popular. Diferentes métodos de streaming de mídia são utilizados na Internet, sendo alguns baseados em RTP (Real Time Protocol - Protocolo de Tempo Real) e RTSP (Real Time Streaming Protocol - Protocolo de Transmissão em Tempo Real). A estrutura e prática do RTP possui semelhança considerável com a entrega baseada em MPEG-2 TS. A suposição de atraso constante na entrega do MPEG-2 TS resultou na necessidade da utilização de um buffer quando utilizado com o RTP como base de entrega. A bufferização e a variabilidade dos largura de banda disponível frequentemente resultam em uma experiência de usuário pouco satisfatória. Este cenário propiciou o desenvolvimento de tecnologia adaptativas conhecidas como o streaming adaptativo HTTP, utilizado para entregar essencialmente todo o conteúdo de streaming IP via banda larga. As diferentes tecnologias de streaming adaptativo HTTP estão convergindo para o MPEG-DASH. O método PCR de MPEG-2 TS depende da suposição de atraso. A ampla disponibi- lidade do UTC na Internet permite o MPEG-DASH eliminar a dependência da entrega por PCR, oferecendo benefícios com respeito a reprodução síncrona de mídia de várias fontes simultaneamente. 64 Ademais, a convergência entre os serviços providos pelos sistemas de TV digital e streaming IP levou a diferentes casos de uso conforme descritos a seguir: • Streaming via Radiodifusão: Todos os componentes são entregues via radiodifusão, entretanto, a experiência do usuário pode ser aprimorada por meio de uma interface baseada em navegador que permite aplicativos interativos serem executados no mesmo ambiente do streaming. • Radiodifusão de Serviços NRT: São serviços em cache que podem ser compostos de combinações essencialmente arbitrárias de texto, mídia e gráficos. • Streaming de Banda Larga: Todos os componentes do serviço são entregues via conexão de banda larga. • Serviços NRT via Banda Larga: A menos que haja uma variação temporal diurna muito substancial na carga da rede que forneça largura de banda ociosa substancial, por ex., durante a noite ou a demanda de item de conteúdo conhecido em cache, a entrega de banda larga não é notavelmente superior ao serviço sob demanda. A alta demanda torna a entrega de serviços NRT atraente. Tornar este cenário eficaz depende de reservas prévias para entrega de conteúdo ou a chamada entrega preditiva. O limite de transição do unicast para radiodifusão é afetada pela arquitetura de rede. Por ex., em uma rede LTE (Long Term Evolution - Evolução de Longo Prazo), o número requerido de usuários de um conteúdo comum pode precisar ser apenas um usuário por célula para fazer a entrega via radiodifusão mais eficiente do que unicast para recepção UHF (Ulta High Frequency - Frequência Ultra Alta). • Serviços Híbridos: Os casos de uso anteriores se concentram principalmente em alto conteúdo de penetração, ou seja, aquele que é melhor servido por radiodifusão, ou conteúdo com interesse estreito o suficiente para ser melhor atendido por meio de entrega de banda larga. Há uma classe de serviços para os quais um único serviço pode ser composto por ambos. Esses componentes de serviço híbrido são, por ex., áudio secundários e texto ou outros componentes de serviço direcionados. Estes cenários de convergência de transmissão de conteúdos por radiodifusão e por conexão banda larga sugerem a necessidade de uma pilha receptora unificada, que pode lidar com toda a diversidade de possíveis tipos de serviço e métodos de entrega. 65 Conforme ilustrado na Figura 13, essa pilha receptora unificada é organizada de modo a permitir uma interface limpa entre as várias camadas e a funcionalidade necessária entre os vários métodos de entrega. Figura 13: Pilha Receptora Unificada Radiodifusão e Banda Larga. Fonte: Traduzido de (ATSC, 2022). A Figura 13 mostra a equivalência da pilha de protocolos onde o protocolo ROUTE/DASH é utilizado (ao lado esquerdo) com a pilha de protocolos tradicional da arquitetura TCP/IP (ao lado direito) aplicada ao serviço de adaptativo, que utiliza o protocolo MPEG/DASH. O protocolo ROUTE/DASH possui nível equivalente ao protocolo de transporte de aplicação HTTP, se conectando abaixo a camada de transporte UDP (User Datagram Protocol - Protocolo de Datagrama do Usuário) e acima aos segmentos DASH, através de uma camada de proxy HTTP (WALKER et al., 2016). Transportando ainda, sinalizações, arquivos, reprodutores, decodificadores DASH, além de aplicações HTML5 e javascript, assim como o protocolo HTTP. Além disso, ele fornece transporte genérico de aplicativo para qualquer tipo de objeto e suporta apresentações incluindo descrições de cenas, objetos de mídia e informações relacionadas a direitos autorais. O protocolo ROUTE/DASH é particularmente adequado para a entrega de conteúdo de mídia em tempo real, oferecendo diferentes recursos: • Entrega individual e acesso a diferentes componentes de mídia. • Suporte para codificador de mídia em camadas, permitindo a entrega de tal ser- viço codificado em diferentes sessões de transporte LCT (Layered Coding Transport - 66 Transporte de Codificação em Camadas. • Fácil combinação com o protocolo MPEG/DASH permitindo sinergia entre a radi- odifusão e a conexão em banda larga. • Rápido acesso à mídia ao ingressar em uma sessão . • Permite a reutilização aprimorada de tecnologias de formato de mídia existentes, nomeadamente DASH e ISO BMFF. O protocolo ROUTE/DASH, definido pela norma ATSC A/331, é um dos formatos contêineres utilizados no sistema de TV digital terrestre ATSC 3.0 (ATSC, 2022) e oferece suporte, por ex., a novos e diferentes tipos de serviços, como os streaming adaptativo via radiodifusão e híbrido, por ex. em caso de queda do sinal terrestre, o sistema continua a transmissão sincronizada do mesmo conteúdo através da conexão banda larga (WALKER et al., 2016). 3.4 Considerações Finais Neste capítulo apresentou-se o estado da arte dos formatos contêineres utilizados atualmente, desde o formato contêiner TS, sintetizado pelo padrão MPEG-2 - Parte 1, passando pelos formatos contêineres sintetizados pelo padrão MPEG-4, chegando aos formatos contêineres mais modernos atualmente, sintetizados pelo padrão MPEG-H - Parte 1, MMT e pela norma ATSC A/331, acrshortROUTE/DASH. Formatos contêineres são utilizados entre outras atividades, para armazenar, trans- portar, sincronizar, multiplexar conteúdos multimídia. No capítulo seguinte (Capítulo 4) serão apresentados o ambiente experimental utili- zado nesta tese, os experimentos realizados e os resultados obtidos. 67 4 USO DO SISTEMA ATSC 3.0 PARA MEDIÇÃO DE LATÊNCIA DE VÍDEO ENTRE BROADCAST E BROADBAND COMO CONTRIBUIÇÃO PARA A PRÓXIMA GERAÇÃO DE TV DIGITAL TER- RESTRE BRASILEIRA Neste capítulo são apresentadas algumas características do sistema ATSC 3.0, bem como algumas considerações sobre ao próximo sistema brasileiro de TV digital, TV 3.0, o ambiente experimental utilizado, experimentos realizados e respectivos resultados. 4.1 Introdução O início das transmissões do sinal analógico de TV terrestre, ainda com visor preto e branco, durante os anos 1930 trouxe grandes mudanças para a sociedade daquela época. Parte da programação que era assistida até então nos cinemas, passou a ser vista em vários pontos das cidades, incluindo-se a casa do usuário. Além disso, abriu-se a possibilidade de assistir-se determinados conteúdos ao vivo. Observou-se a partir da década de 1950 uma nova revolução tecnológica, a evolução da televisão analógica preta e branca para a televisão analógica em cores. Vários sistemas foram desenvolvidos no planeta, como o PAL (Phase Alternating Line - Linha Alternada de Fase) G alemão, o NTSC (National Television System Committee - Comitê do Sis- tema de Televisão Nacional) M estado unidense, o PAL-M brasileiro, o SECAM (Système Électronique Couleur Avec Mémoire - Electronic Color System With Memory - Sistema Eletrônico de Cores com Memória) franco-soviético entre outros. A fim de compatibilizar os diferentes sistemas de TV em cores analógicos existentes fo- ram desenvolvidos com o passar do tempo os receptores multinorma, isto é, que suportam diferentes padrões de TV em cores, como por ex., o PAL-M, PAL-N e o NTSC-M. Uma nova revolução tecnológica se inicia durante a década de 1990 com o advento da TV digital terrestre. Novos paradigmas são adotados, além de todas as melhorias advindas 68 do uso de técnicas de modulação e transmissão digitais, utilizam-se técnicas de compressão digital do conteúdo de áudio e vídeo, rompendo-se com retro compatibilidade entre os sistemas analógicos de TV e os novos sistemas de TV digital nascentes, por consequência da digitalização e compressão dos sinais de áudio e vídeo e dos novos receptores de TV digital terrestre, demandados pela nova tecnologia (ATSC, 2022). Vários sistemas de TV digital terrestre foram desenvolvidos contemplando diferentes fatores, necessidades ou premissas, tais como: a realidade geográfica de cada região, realidade socioeconômicas, tecnologia disponível. A seguir, são descritas algumas características to sistema ATSC, o primeiro sistema de TV digital implementado mundialmente, posteriormente atualizado para se tornar o sistema de TV digital comercial mais avançado atualmente. 4.1.1 ATSC – Advanced Television Standard Comitte Ao iniciar seus trabalhos, o ACATS (Advisory Committee on Advanced Television Ser- vice - Comitê Consultivo sobre Serviço de Televisão Avançada) tomou uma decisão que viria a alterar radicalmente o curso dos desenvolvimentos: ao contrário dos modelos hí- bridos propostos por Japão e Europa, ele propôs um sistema totalmente digital, batizado de DTV (Digital Television - Televisão Digital). Com isso, abandonava-se definitivamente a tentativa de criar um padrão compatível com os sistemas analógicos tradicionais. Para resolver o problema da transição (coexistência de receptores analógicos e digitais), du- rante essa fase, o mesmo programa deveria ser transmitido simultaneamente pelo sistema analógico e pelo novo sistema digital, utilizando dois canais distintos – o simulcasting. A fim de testar as diferentes propostas que surgiram foi criado um laboratório chamado de ATTC (Advanced Television Test Center - Centro de Teste de Televisão Avançada). Em 1993, sete empresas e instituições participantes dos testes (ATT, GI, MIT, Phillips, Sarnoff, Thomson, Zenith entre outras) resolveram unir seus esforços na chamada “Grande Aliança”, visando desenvolver um padrão unificado que englobasse as principais vantagens dos sistemas-candidatos. No final de 1995, o ATSC, órgão responsável por documentar o novo sistema de TV, recomenda à FCC (Federal Communications Commission - Comissão Federal de 69 Comunicações) adotar o sistema da Grande Aliança como o padrão para a DTV estado unidense. Em dezembro de 1996, a FCC adota o sistema desenvolvido pela Grande Aliança, como sendo o padrão para a DTV norte americana, utilizando o padrão MPEG para compressão de áudio e vídeo, entrando em operação em novembro de 1998 (WU et al., 2006). 4.1.2 Transição para o Sistema ATSC 3.0 Em março de 2013, o ATSC anunciou a CfP para a camada física do novo sistema de TV digital terrestre, denominado ATSC 3.0, afirmando que o plano é que o sistema suporte vídeo com uma resolução de UHD 4K (2160p@60). Os objetivos do ATSC 3.0 eram o de melhorar a experiência de assistir TV com maior qualidade de áudio e vídeo, transmissão robusta para recepção em dispositivos fi- xos e móveis, recepção aprimorada e mais flexível em dispositivos fixos e móveis e mais acessibilidade, personalização e interatividade. Abordando ainda, as mudanças no com- portamento e nas preferências do consumidor, fornecendo conteúdo de TV em uma ampla variedade de dispositivos, sem a restrição de compatibilidade com o sistema legado. Além disso, o ATSC 3.0 tem por concepção que a transmissão de TV se torne parte da Internet, o que permite a criação de novos serviços e modelos de negócios para as emissoras de TV, além da evolução mais próxima do ritmo de evolução da Internet. O uso do transporte IP também permite a incorporação de serviços híbridos, onde os componentes dos serviços podem ser entregues por transmissão e banda larga de forma que possam ser sincronizados e combinados conforme necessário para criar serviços, sendo assim o primeiro sistema de TV digital terrestre basedo em tecnologia IP (CHERNOCK et al., 2016). A integração da transmissão do sinal de TV com a Internet requisitado pelo sistema ATSC 3.0 pode ser percebida em sua pilha de protocolos, conforme ilustrado na Figura 14. A coluna situada completamente a direita da Figura 14, destacada em vermelho, segue estritamente pilha de protocolos TCP/IP para conexão do sistema à Internet, onde na 70 camada de transporte utiliza-se o protocolo TCP, para transportar o serviço MPEG- DASH. Esta coluna está identificada como conexão banda larga (broadband). Destacada em amarelo e situada ao lado esquerdo da coluna de conexão banda larga, situa-se a primeira coluna dedicada ao serviço de radiodifusão, onde identifica-se o serviço ROUTE/DASH . Da mesma forma que a coluna do serviço de banda larga, esta coluna segue a arquitetura da pilha de protocolos TCP/IP, onde na camada de transporte é utilizado o serviço ROUTE/DASH. Da mesma maneira que a coluna anterior, o protocolo de transporte ROUTE é utilizado para transporte do serviço DASH. Destacada em verde e posicionada ao lado esquerdo da coluna que ilustra o serviço ROUTE/DASH, encontra-se a segunda coluna dedicada ao serviço de radiodifusão, onde identifica-se o serviço MPU. Assim como as duas colunas anteriores, esta coluna tam- bém segue a arquitetura da pilha de protocolos TCP/IP, onde na camada de transporte é utilizado o protocolo MMTP (MPEG Multimedia Transport Protocol - Protocolo de Transporte Multimídia MPEG), para transporte do serviço de MPU. Por fim, a coluna situada mais a esquerda da Figura 14, destacada em roxo, é dedicada ao transporte de dados de sinalização necessários para todo sistema. Figura 14: Pilha de protocolos do sistema ATSC 3.0. Fonte: (ATSC, 2022). A camada física do sistema ATSC 3.0 possui algumas vantagens em relação ao sistema antecessor, o ATSC 1.0, conforme listado a seguir: • Utilização de modulação OFDM (Orthogonal Frequency Division Multiplexing - Multiplexação por Divisão de Frequência Ortogonal). 71 • Utilização de Constelações NUC (Non-Uniform Constellation - Constelação Não Uniforme): Constelações em que seus pontos não são uniformemente distribuídos no plano ortogonal e portanto a distância euclidiana entre seus símbolos não é constante (LOGHIN et al., 2016). • Utilização de código corretores de erro LDPC (Low Density Parity Check - Veri- ficação de Paridade de Baixa Densidade) e BCH (Bose Chaudhuri Hocquenghem - Bose Chaudhuri Hocquenghem): LDPC é um código corretor de erro baseado em matrizes, de cuja capacidade de correção de erros se distancia apenas 0,06 dB do limite teórico de Shannon. Geralmente o código LDPC é utilizado em concatenação com o código BCH, que é um código linear, cíclico e binário, cuja teoria matemática se baseia no campo de Galois (KIM et al., 2016). • Suporte ao recurso de LDM (Layered Division Multiplexing - Multiplexação por Divisão de Camadas): Tecnologia não ortogonal de multiplexação de sinais, permitindo que múltiplos sinais sejam transmitidos simultaneamente com diferentes níveis de potência e robustez A separação dos sinais transmitidos é feita com base no cancelamento de camadas de sinal (ZHANG et al., 2016). • Suporte a sistemas de transmissão SFN (Single Frequency Network - Rede de Frequência Única). • Suporte a sistema MIMO: Método de transmissão que permite o aumento da capa- cidade do canal através da adição de sinais com diferentes polarizações dentro do mesmo canal de RF (GOMEZ-BARQUERO et al., 2016). • Suporte a Channel Bonding: Método de transmissão que permite o aumento da capacidade de transmissão de um sinal através do agregamento de diferentes canais de RF (Stadelmeier et al., 2016). • Utilização de PLP (Physical Layer Pipe - Tubo de Camada Física): Recurso que configurar diferentes serviços com diferentes níveis de robustez oferecendo mais flexibili- dade ao sistema e permitindo o receptor selecionar e decodificar somente o PLP desejado (JEONG et al., 2016). • Utilização de Bootstrap: Recurso que permite o receptor identificar o sinal ATSC 3.0 recebido (HE et al., 2016). 72 Em março de 2016, a norma do sistema ATSC 3.0 foi publicada e a primeira utilização deste sistema foi feita para a cobertura dos Jogos Olímpicos Inverno de 2018 na Coreia do Sul em formato UHD 4K. O sistema ATSC 3.0 é utilizado atualmente nos Estados Unidos, Coreia do Sul e Jamaica (ATSC, 2022). 4.2 Propostas e Estudos em Direção à Próxima Geração de TV Digital Brasileira Com o intuito de estudar, experimentar e propor novas alternativas ao novo sistema de TV digital brasileiro (TV 3.0), diferentes estudos foram feitos pela academia. Por ex., estudos de desempenho, usabilidade, gameficação e viabilidade da transmissão de conteúdo de vídeo adicional à programação corrente, utilização de MW IBB HbbTV (Hybrid Broadcast Broadband TV - TV de Transmissão Híbrida com Banda Larga) para interatividade (HBBTV, 2020), além da utilização de dispositivo móvel para participação de quiz interativo (AKAMINE et al., 2018). Além de um estudo comparativo da robustez do atual sistema ISDB-Tb e do novo ATSC 3.0 contra diferentes tipos de distorções, como ruído impulsivo, multi-percurso entre outras, uma vez que qualquer outro sistema candidato a suceder o atual sistema de TV digital utilizado no Brasil deve ser no mínimo tão robusto quanto este (Oliveira et al., 2019). Assim como, as principais formas de transmissão e principais vantagens da utilização de vídeo escalável para a TV 3.0 (Vaz; Alves; Akamine, 2020). Várias novas e diferentes tecnologias deverão fazer parte da TV 3.0, tais como: • Códigos corretores de erro LDPC e BCH. • Relação portadora ruído (C/N) <= 0 dB. O que permite o reuso unitário de frequên- cia, de forma que uma emissora de TV possa cobrir todo território nacional utilizando somente um único canal físico. • Técnicas de modulação NUC. 73 • Suporte a recursos de accessibilidade. • Suporte a vídeo UHD (4K e 8K). • Suporte a áudio e vídeo escaláveis. A fim de contribuir com os estudos e avanços em direção ao novo sistema de TV digital brasileiro, tem-se como proposta a utilização do recurso de streaming de vídeo escalável, com o intuito de enriquecer a resolução de imagem transmitida pelo ar, da resolução de FHD 2K para UHD 4K, com sincronismo de conteúdos feito através de protocolo ROUTE/DASH. Através do recurso de vídeo escalável, podem-se transmitir conteúdo de vídeo com diferentes resoluções, para diferentes tipos de receptores, com melhor eficiência de codifi- cação e transporte, se comparado com a transmissão destes conteúdos independentemente através do simulcasting (Boyce et al., 2016). O conteúdo adicional (EL) recurso de vídeo escalável poderia ser transmitido para o receptor de TV digital através de diferentes formas (Vaz; Alves; Akamine, 2020): 1. Internet (Streaming) - Opção já está disponível na TV 2.5, pela qual será possí- vel ofertar serviços de UHD 4K por streaming simultaneamente ao conteúdo OTA, dependo da disponibilidade de conteúdo de cada emissora. 2. LDM – Opção de camada física que não está presente na TV 2.5 e que dependeria de um novo sistema de TV digital para ser utilizada. Entretanto este recurso não faz parte dos requisitos da para TV 3.0. 3. Channel Bonding – Opção de camada física não nativa da TV 2.5, entretanto que através de adaptações é de possível implementação, através de receptores protótipos especiais com dois ou mais sintonizadores. Esta opção é um dos requisitos da TV 3.0, entretanto requer receptores de TV com mais de um sintonizador, o tornando mais caro e complexo que um receptor de um único sintonizador. 4. MIMO - Opção de camada física que utiliza somente um canal físico e não está presente na TV 2.5. Esta opção é um dos requisitos da TV 3.0, entretanto sua implementação demanda o uso de dois sintonizadores, antenas de TX/RX MIMO, o que torna sua implementação e utilização comercial mais cara e complexa em 74 relação ao sistema SISO (Single Input Single Output - Entrada Única Saída Única) (SAITO et al., 2016) e (GOMEZ-BARQUERO et al., 2016). Embora todas estas possibilidades sejam tecnicamente factíveis, algumas são de im- plementação menos custosa ou mais prática do que outras. Conforme mencionado anteriormente, as hipóteses 3 e 4 demandam que dois ou mais sintonizadores estejam disponíveis no receptor, o que tornará este tipo de receptor mais caro e complexo que um receptor com um único sintonizador. A hipótese 4 possui uma dificuldade adicional, pois necessita de uma antena preparada para recepção do sinal de TV na duas polarizações para pode tirar proveito da vantagem oferecida pela forma MIMO de poder até dobrar a capacidade do canal, ao passo que as outras três hipóteses demandam somente uma antena de recepção de TV comum. A possibilidade 2 não está contemplada nos requisitos da TV 3.0. Além disso, sua im- plementação demandaria a especificação de um novo sistema, com uma nova camada física e por consequência, um novo receptor a ser desenvolvido para receber esta configuração de sinal. A possibilidade 1 (Streaming pela Internet) se mostra, dentre as quatro hipóteses mencionadas, como a hipótese de estudos para contribuição de avanço para o novo sistema de TV digital mais praticável e interessante, dado o atual contexto de crescimento de acesso à Internet banda larga brasileiro. Deve-se ressaltar, que apesar de todos os avanços tecnológicos vivenciados atualmente, ainda há carência de produção e transmissão de conteúdo de vídeo UHD 4K e/ou UHD 8K. Comercialmente, conteúdos UHD 4K são encontrados em serviços de streaming como YouTube ou Netflix, mídia física de Blu-Ray UHD 4K e em alguns eventos demonstrativos, como concertos musicais, copa do mundo ou jogos olímpicos, em sistemas de TV por cabo ou satélite. Esta situação se agrava ainda mais se considerado vídeo UHD 8K, onde comercial- mente este conteúdo é encontrado basicamente em serviço de streaming YouTube ou em alguns eventos demonstrativos. Ressalta-se ainda que esta resolução não está inclusa 75 ainda no Guia Operacional do fórum UHD internacional (FORUM, 2022). Mesmo o sistema ATSC 3.0, sistema comercial de TV digital terrestre comercialmente mais avançado atualmente, enfrenta problemas com relação a carência de conteúdo UHD. Algumas demonstrações foram realizadas para estudar a transmissão do conteúdo UHD 4K escalável (SHVC), porém nunca foi empregado comercialmente (TEAMCAST, 2018) e (TEAMCAST ATEME, 2018). 4.3 Ambiente Experimental A configuração experimental adotada nesta tese utiliza para transmissão e multiple- xação do sinal de TV OTA o sistema ATSC 3.0 no formato estado unidense, por ser atualmente o sistema de TV digital terrestre comercial mais avançado, além de contar com suporte ao recurso de streaming escalável via Internet (ATSC, 2022). O conteúdo de vídeo escalável é codificado através do padrão padrão MPEG-H - Parte 2/ITU-T H.265 - SHVC (por ser o padrão de codificação de vídeo com suporte a vídeo escalável mais avançado no momento em que iniciou-se os trabalhos de pesquisa desta tese - janeiro de 2018 - além de ser maduro comercialmente) para codificação do vídeo escalável de FHD 2K para UHD 4K, com sincronismo de conteúdos feito através de protocolos ROUTE/DASH. Ressalta-se que padrões de codificação de vídeo mais avançados que o padrão MPEG- H - Parte 2/ITU-T H.265 - SHVC, foram padronizados recentemente, carecendo ainda de ferramentas de referência e de codificadores comerciais (MCCANN, 2019), (Bross et al., 2021), (Battista et al., 2022). Ademais, os resultados obtidos nesta pesquisa não seriam impactados se outros padrões de codificação de vídeo fossem utilizados, de acordo com os objetivos estabelecidos neste projeto, de medir a latência de transporte entre os BL e o EL, uma vez que a Internet transporta pacote de dados. Quem entende seu significado, o processando é o receptor (Vaz et al., 2023a). Certamente a latência de decodificação de vídeo de acordo com o padrão de codificação de vídeo utilizado (por ex. o padrão MPEG-H - Parte 2/ITU-T H.265 - SHVC ou padrão MPEG-I - Parte 3/ ITU-T H.266 - VVC) seria diferente tendendo a ser maior quando mais novo for o padrão de codificação de vídeo utilizado. 76 Entretanto, estudos da dos impactos da latência de decodificação de vídeo sobre a decodificação do vídeo escalável e sobre a experiência do usuário não fazem parte do escopo desta tese. O protocolo de camada de transporte ROUTE/DASH foi selecionado por ser o pro- tocolo comercialmente mais maduro e com ampla disponibilidade comercial de soluções e posteriormente adotado como solução pela TV 3.0 por este motivos (SBTVD, 2024). O protocolo de camada de transporte MMT, embora muito avançado, possui muito pouca maturidade comercial ou implementação de soluções comerciais. A Figura 15 ilustra o diagrama de interconexão física dos equipamentos utilizados neste ambiente experimental. Todos os equipamentos possuem interface de rede e são conectados a um switch permitindo que sejam desempenhadas, além das funcionalidades para as quais foram projetados, o controle remoto destes via Internet. Próximo a cada bloco funcional está informado o respectivo endereço IP, entretanto, os blocos funcionais Codificador de Vídeo e Mux/Scheduler possuem dois endereços IPs, denotados por in ou out. Estes dois blocos possuem duas interfaces de rede, sendo a interface in, a interface por onde este bloco recebe os comandos de controle remoto, além de receber os dados de entrada a serem processados e os devolver processados ao ambiente experimental através da interface out. Figura 15: Diagrama de Interconexão Física dos Equipamentos. Fonte: Adaptação da Chamada de Testes para Fase 2 da TV 3.0 do Fórum SBTVD (SBTVD, 2024). 77 Ademais, a Figura 15 mostra através do prisma de infraestrutura a integração do sistema ATSC 3.0 com a rede de dados. O servidor NTP (Network Time Protocol - Protocolo de Tempo da Rede) é responsável por fornecer o relógio para sincronia do sistema experimental A Figura 16 ilustra o diagrama lógico de interconexão dos equipamentos utilizados neste ambiente experimental, mostrando a cadeia de transmissão do sinal de TV ATSC 3.0 desde a reprodução e codificação de vídeo, multiplexação de A/V e dados, chegando até o modulador, bem como a recepção do sinal e respectiva análise pelo programa de referência. Figura 16: Diagrama Lógico de Conexão dos Equipamentos. Fonte: Adaptação da Chamada de Testes para Fase 2 da TV 3.0 do Fórum SBTVD (SBTVD, 2024). A identificação e funcionalidade de cada bloco apresentado nas Figuras 15 e 16 são feitos a seguir: 1. Conteúdos de Vídeo UHD 4K São utilizados os conteúdos de vídeo de referência UHD 4K (3840x2160p@60) in- ternos do Laboratório de TV Digital da Escola de Engenharia da Universidade Presbiteriana Mackenzie para codificação do vídeo escalável UHD 4K (BL FHD 2K 78 e EL UHD 4K). O conteúdo de vídeo é reproduzido pelas ferramentas instaladas no bloco Notebook: Playout + Controle e enviado por estas ao codificador de vídeo. 2. Codificação de Vídeo A codificação dos conteúdos de vídeo (escalável) é feita através do uso das seguintes ferramentas: • DigiCAP - PCAP Stream Generator Programa de computador, nas Figuras 15 e 16 é instalado no bloco Notebook: Playout + Controle, responsável pela reprodução de arquivos multimídia em for- mato PCAP (Packet Capture - Captura de Pacotes), tendo sido desenvolvido pela Digicap com o objetivo de alimentar o codificador de vídeo com o conteúdo multi- mídia desejado. Esta ferramenta entrega o arquivo multimídia desejado ao codificador de vídeo atra- vés do protocolo Multicast UDP (DIGICAP, 2020). • ATEME - Titan Equipamento de codificação de vídeo em tempo real com relação ao padrão MPEG- H - Parte 2/ITU-T H.265 - SHVC, fabricado pela Ateme, suportando até o momento a resolução de UHD 4K. Nas Figuras 15 e 16 é representado no bloco Codificador de Vídeo. Por suas características de implementação, este equipamento opera no sistema ATSC 3.0 no formato estado unidense, recebendo o conteúdo multimídia a ser co- dificado através do protocolo Multicast UDP e entregando o conteúdo codificado de vídeo ao multiplexador através do serviço WEBDAV (Web Distributed Autho- ring and Versioning - Criação e Controle de Versão Distribuído Baseado na Rede) (ATEME, 2020). WEBDAV é um conjunto de extensões para o protocolo HTTP que permite aos usuários editar e gerenciar de forma colaborativa os arquivos em servidores remotos, oferecendo diferentes vantagens ao usuário, como (WEBDAV, 2020): • Integração nativa em todos os principais sistemas operacionais (como Win- dows, Linux e Mac) sem a necessidade de instalar ferramentas de terceiros 79 para sua utilização. • Suporte a transferências parciais de dados. • Suporta diferente opções de autenticação. • LINUX PC Servidor WEBDAV construído em ambiente Linux destinado a gravar os segmentos de vídeo produzidos pelo codificador Ateme com a finalidade de estudar a arquite- tura e funcionamento dos arquivo manifest.mpd a fim de separar os fluxos de vídeo a serem transmitidos por RF e por Internet. Nas Figuras 15 e 16 é representado pelo bloco Servidor de Vídeo (Linux PC). 3. Camada de Transporte • DigiCAP - Digicaster Multiplexer O equipamento multiplexador fabricado pela Digicap, nas Figuras 15 e 16 represen- tado no bloco Mux/Scheduler, sendo responsável pelo empacotamento de dados de sinalização, BL (FHD 2K ou UHD 4K), EL (UHD 4K ou UHD 8K) recebidos do codificador de vídeo em pacotes MMT e/ou ROUTE/DASH, para transmissão via Internet. O multiplexador é internamente formado por dois módulos: o packager e o mul- tiplexador propriamente dito. Onde o packager recebe do codificador de vídeo o conteúdo codificado através do serviço WEBDAV, o convertendo para Multicast UDP e entregando-o para o multiplexador. Este por sua vez adiciona informações de sinalização e entrega o conteúdo utilizando o protocolo ROUTE/DASH como camada de transporte ao scheduler através do protocolo Multicast UDP (DIGICAP, 2020). • DigiCAP - Digicaster Scheduler O equipamento fabricado pela Digicap, nas Figuras 15 e 16 representado no bloco Mux/Scheduler, sendo responsável pelo encapsulamento de um ou vários fluxos IP proveniente do multiplexador, além de dados de sinalização e modulação para serem entregues para o modulador através do protocolo STL (Studio to Transmitter Link - Enlace do Estúdio para o Transmissor). 80 O scheduler recebe os dados provenientes do multiplexador através do protocolo Multicast UDP, adicionando as devidas sinalizações, entregando o conteúdo proces- sado ao modulador através através do protocolo Multicast UDP (DIGICAP, 2020). 4. Transmissão • Pro Television - Modulator O equipamento modulador e transmissor ATSC 3.0, nas Figuras 15 e 16 representado no bloco Modulador, de modelo PT3063, foi desenvolvido pela Pro Television com capacidade de transmitir o sinal terrestre de TV digital dentro do espectro de VHF (Very High Frequency - Frequência Muito Alta) e UHF. O modulador recebe os dados provenientes do equipamento scheduler através do protocolo Multicast UDP, interpretando as sinalizações anexadas, modulando o sinal de TV de acordo com as especificações do sistema ATSC 3.0 (PROTELEVISION, 2020). 5. Recepção • Clever Logic - ATSC 3.0 Lite Receiver O receptor ATSC 3.0 de referência, nas Figuras 15 e 16 representado no bloco Receptor de Referência, de modelo CLA3-LR1000N, projetado pela Clever Logic, é responsável pela recepção do sinal ATSC 3.0 e por prover parâmetros para análise e medição do respectivo sinal recebido (CLEVER_LOGIC, 2020). • Agos - IMAS (Integrated Measurement Analysis Software) O programa IMAS (Integrated Measurement & Analysis Software - Programa de Análise e Medição Integrados) desenvolvido pela AGOS, nas Figuras 15 e 16 re- presentado no bloco Desktop IMAS, é responsável pelo monitoramento e análise da camada física para o sistema ATSC 3.0 OTA. O programa provê medidas automati- zadas dos sinais fixo e móvel trabalhando em conjunto com o receptor de referência e um analisador de espectro, além de suportar múltiplos streams baseados nos padrões MMT e ROUTE/DASH e vídeo UHD 4K (AGOS, 2020). • GPAC - Streaming Video Player GPAC (Project on Advanced Content - Projeto de Conteúdo Avançado), nas Fi- guras 15 e 16 instalado no bloco Desktop IMAS, é uma implementação de código 81 aberto dos sistemas MPEG-4, dedicada a rich-media e a tecnologias de transmissão, sendo escrita em linguagem ANSI (American National Standards Institute - Insti- tuto de Padrões Nacional Americano) C, compatível com sistemas Linux e Windows e que provê ferramentas de reprodução multimídia, renderização 3D e de autoração MPEG-4. O projeto é destinado a um amplo público que vai desde usuários finais ou criadores de conteúdo com habilidades de desenvolvimento, que desejam experimentar os novos padrões para tecnologias interativas ou que desejam converter arquivos para dispositivos móveis, a desenvolvedores que precisam de reprodutores e/ou servidor para aplicações de streaming multimídia. A ferramenta é mantida pela Telecom Paris e tem sido ativamente suportada por programas de pesquisa da França e da União Europeia e suporta a reprodução de conteúdos de vídeo codificados pelos os padrões de vídeo MPEG-4 - Parte 10/ITU-T H.264 - AVC, MPEG-H - Parte 2/ITU-T H.265 - HEVC entre outros, bem como vídeo escalável e o padrão MPEG-DASH (GPAC, 2020). 6. Analisador de Transporte • Kai Media - ATSC 3.0 Multi Player (Analyzer) O equipamento KMR-U4K, nas Figuras 15 e 16 representado no bloco Analisador de Transporte, foi desenvolvido pela Kai Media é um dispositivo que permite decodificação multicanal em tempo real de fluxos MMT e ROUTE/DASH e monitoramento para suportar transmissão de conteúdo de vídeo UHD baseada no sistema ATSC 3.0 (KAI_MEDIA, 2020). 7. Internet • Acesso a Serviços e à Internet Representado pelo bloco Internet, utilizou-se para acesso à mesma um plano de assinatura comercialmente disponível com velocidade de download de 500 Mbps e upload de 50 Mbps. Ademais, utilizou-se uma rede CDN (Content Delivery Network - Rede de Entrega de Conteúdo) externa, neste caso provida gratuitamente pelos serviços da AWS (Amazon Web Services - Serviço de Rede da Amazon) (AWS, 2022a). 82 4.4 Transmissão do Conteúdo de Vídeo Escalável A primeira etapa da pesquisa foi a configuração dos equipamentos utilizados no am- biente experimental responsáveis pela transmissão de conteúdos de vídeo escalável BL + EL via RF através do protocolo ROUTE/DASH. Os conteúdos de vídeo utilizados possuem resolução HD (High Definition - Definição Alta) 1280x720i@29,97, onde o BL é configurado com resolução SD (Standard Definition - Definição Padrão) 720x480i@29,97 - bitrate de 2 Mbps e o EL é configurado com resolução HD 1280x720i@29,97 - bitrate de 2,5 Mbps, além de resolução UHD de 3840x2160p@29,97, onde o BL é configurado com resolução FHD 1920x1080p@29,97 - bitrate de 2 Mbps e o EL é configurado com resolução UHD 3840x2160p@29,97 - bitrate de 2,5 Mbps. O codificador de vídeo foi configurado para gerar segmentos de vídeo com duração de aproximadamente 2 s cada um. Deve-se salientar que até o momento em que os testes pertinentes a esta tese foram realizados, os relatórios de avaliação subjetiva da qualidade de vídeo não estavam dispo- níveis. Desta maneira, adotou-se o valor de 2 Mbps para a taxa de transmissão de vídeo do BL (SBTVD, 2024). O codificador de vídeo transmite o conteúdo de A/V comprimido através do protocolo DASH, utilizando o protocolo WEBDAV. Em seu primeiro estágio de processamento, o multiplexador converte a recepção de dados feita através do protocolo MPEG-DASH no protocolo UDP, dado que todo proces- samento e fluxo de dados feito dentro do equipamento multiplexador utiliza o protocolo UDP. Dentro do multiplexador é configurado o serviço 6002, utilizado para transmissão de conteúdos de A/V, assim como a sinalização para transmissão do conteúdo de vídeo esca- lável ao scheduler. O serviço 6002 é transmitido utilizando-se o protocolo ROUTE/DASH via IP 239.255.60.2:6002, canal 60-2. Todos estas informações são ilustradas na Figura 17 O scheduler configura o campo Subframe 1, que é responsável por informar parâmetros de modulação do sinal, parâmetros do código corretor de erro utilizado, a quantidade de 83 Figura 17: Serviços 6002 no Multiplexador. Fonte: Foto Tirada da Tela do Multiplexador (2021). PLPs utilizados com os serviços transportados, respectivos tamanhos de PLP. Conforme ilustra a Figura 18, o scheduler transmite as camadas de vídeo ao modula- dor através de dois PLPs: o PLP0 transmite o serviço 6002 com o BL e o PLP1 transmite o serviço 6022 com o EL. Ambos PLPs utilizam modulação 256 QAM (Quadrature Am- plitude Modulation - Modulação de Amplitude em Quadratura) NUC. Os códigos de correção de erros utilizados são os códigos LDPC e BCH, sendo primei- ramente utilizado o código LDPC com comprimento de 64800 e posteriormente o código BCH (outter code) com razão de 8/15. A taxa média de transmissão de transmissão do PLP0 e do PLP1 é de 4,9 Mbps cada um. A taxa média de transmissão do serviço 6002 é de 2,28 Mbps do serviço 6022 é de 2,55 Mbps. Figura 18: Configuração dos PLPs no Scheduler. Fonte: Foto Tirada da Tela do Scheduler (2021). Optou-se por não utilizar o recurso de LDM e manter-se os mesmos parâmetros de modulação para ambas, a fim de evitar eventuais latências na recuperação das camadas de vídeo. 84 4.5 Recepção do Conteúdo de Vídeo Escalável Em ambos os casos de transmissão dos conteúdos de vídeo através do protocolo ROUTE/DASH, a análise do sinal de TV recebido e reprodução dos conteúdos de ví- deo foram realizadas com sucesso através das ferramentas IMAS e GPAC. De acordo com a Figura 19, o sinal de TV com resolução de vídeo HD 1280x720i@29,97 recebido e analisado pelo IMAS é coerente com o sinal transmitido, possuindo dois PLPs, onde cada um foi modulado em 256QAM, utilizando os códigos corretores de erro LDPC (com comprimento de 64800) e BCH (com razão de 8/15) e sem a utilização do recurso de LDM. Figura 19: Análise do Sinal ATSC 3.0 via IMAS. Fonte: Foto Tirada da Tela de Execução da Ferramenta IMAS. As camadas de vídeo BL e EL foram reproduzidas com sucesso pela ferramenta GPAC. A avaliação inicial pode ser feita de forma subjetiva por inspeção visual, observando- se as Figura 20 e Figura 21, onde a Figura 20 mostra a reprodução do BL (camada que possui menor resolução espacial) e a Figura 21 mostra a reprodução da combinação BL + EL. Desta maneira, percebe-se que o conteúdo de vídeo exibido pela Figura 21 possui maior resolução espacial que o conteúdo exibido pela Figura 20. A ferramenta GPAC fornece informações objetivas a respeito dos conteúdos de vídeo que estão sendo recebidos e reproduzidos, como a resolução espacial e taxa de transmissão. Conforme indicado na extremidade superior da Figura 20, o conteúdo do BL está sendo reproduzido conforme a resolução espacial de vídeo desta camada - SD 720x480. Assim como, a extremidade superior da Figura 21 ilustra a reprodução do EL conforme sua 85 Figura 20: BL - Resolução Espacial (720x480). Fonte: Foto Tirada da Tela de Execução da Ferramenta GPAC. Figura 21: BL + EL - Resolução Espacial (1280x720). Fonte: Foto Tirada da Tela de Execução da Ferramenta GPAC. 86 resolução espacial de vídeo HD 1280x720. Na Figura 21 a taxa de transmissão aproximada do conteúdo de vídeo recebido é de 4,5 Mbps, o que é coerente com a taxa de transmissão de ambas camadas de vídeo (BL + EL), conforme configurado no codificador de vídeo. As camadas de vídeo BL e EL foram reproduzidas com sucesso pelo GPAC. Assim como realizado para as recepções anteriores, pode-se prosseguir por inspeção visual, observando-se as Figura 22, que mostra a reprodução da BL (camada que possui menor resolução espacial) com resolução de vídeo de FHD 1920x1080 e a Figura 23, que mostra a reprodução da combinação BL + EL com resolução UHD 3840x2160. Conforme observa-se nas Figuras 22 e 23, no caso de resoluções mais elevadas a dife- rença de resolução de imagem não é tão perceptível devido as limitações dos monitores de computadores utilizados até o momento, que não suportam nativamente as resoluções espaciais utilizadas nestes conteúdos de vídeo. Figura 22: BL - Resolução Espacial (1920x1080). Fonte: Foto Tirada da Tela de Execução da Ferramenta GPAC. Evidencia-se neste caso a necessidade de uma avaliação objetiva dos vídeo recebidos e reproduzidos. Através da ferramenta GPAC, resgata-se informações objetivas a respeito dos conteúdos de vídeo recebidos e reproduzidos, como sua resolução espacial e taxa de transmissão. 87 Figura 23: BL + EL - Resolução Espacial (3840x2160). Fonte: Foto Tirada da Tela de Execução da Ferramenta GPAC. Conforme indicado na extremidade superior da Figura 22, o conteúdo do BL está sendo reproduzido conforme a resolução espacial de vídeo desta camada - FHD 1920x1080. Assim como, a extremidade superior da 23 ilustrada reprodução do EL conforme sua reso- lução espacial de vídeo UHD 3840x2160. Na Figura 23 a taxa de transmissão aproximada do conteúdo de vídeo recebido é de 4,5 Mbps, o que é coerente com a taxa de transmissão de ambas camadas de vídeo (BL + EL), conforme configurado no codificador de vídeo. 4.6 Estudo Off-Line para Transmissão do BL e do EL por Meios Distintos A fim de separar os fluxos de vídeo a serem transmitidos por RF e por Internet de forma a não depender dos fabricantes de equipamentos, é necessário melhor entender a forma de entrega de conteúdos de vídeo pelo codificador Ateme através do protocolo WEBDAV, bem como as propriedades e funcionamento do arquivo manifest.mpd gerado por este equipamento. A separação dos fluxos de vídeo transmitidos por OTA e Internet é melhor ilustrada na Figura 24, que mostra a transmissão e recepção do BL e do EL. A separação entre 88 as camadas de vídeo deve ser feita no multiplexador, onde o BL é entregue ao scheduler, posteriormente modulado e transmitido via RF ao receptor. O EL é transmitido via rede de dados ao receptor, que ao receber ambas camadas de vídeo realiza a união das duas e exibe o vídeo com qualidade aprimorada na em sua tela. Figura 24: Diagrama de Blocos de Transmissão dos BL e EL por Meios Distintos. Fonte: Traduzido de (Vaz et al., 2023a). Desta maneira, construiu-se um servidor WEBDAV em ambiente Linux que permite gravar os segmentos de vídeo produzidos pelo codificador Ateme, gravar e editar o arquivo manifest.mpd e fazer testes de reprodução de conteúdo de maneira Off-Line. A reprodução de conteúdo de maneira Off-Line fez-se necessária dado o contexto de pandemia de COVID-19, que ocorreu entre os anos de 2020 e 2023, de forma que os trabalhos tiveram que ser realizados de maneira remota. Ademais, a realização de trabalhos de forma Off-Line facilitou a realização de testes de reprodução de vídeo devido a possibilidade de utilização de conteúdo gravado previamente e de configuração conhecida. O arquivo manifest.mpd é um arquivo de formato XML (Extensible Markup Language - Linguagem de Marcação Extensível) que descreve a apresentação de mídias, conforme indica sua própria extensão MPD Media Presentation Description - Descrição de Apre- sentação de Mídia (ISO/IEC, 2022). Inicialmente gravou-se os segmentos de vídeo no servidor WEBDAV Linux, assim como o arquivo manifest.mpd. Após a gravação, modificou-se os seguintes campos do arquivo manifest.mpd, o que 89 permitiu a com sucesso a reprodução Off-Line do conteúdo de vídeo (ISO/IEC, 2022): • Type: Especifica o tipo de apresentação de mídia. Para apresentações de mídia es- táticas (@type=”static”), todos os segmentos estão disponíveis entre os @availabilityStart- Time e @availabilityEndTime. Para apresentações de mídia dinâmicas (@type=”dynamic”), os segmentos geralmente têm horários de disponibilidade diferentes. Além disso, a descri- ção da apresentação de mídia pode ser atualizada em apresentações de mídia dinâmicas, ou seja, o @minimumUpdatePeriod pode estar presente. Apresentações de mídia estáticas são normalmente usadas para serviços sob demanda, enquanto as apresentações de mídia dinâmicas são usadas para serviços ao vivo. O co- dificador de vídeo Ateme configura este campo inicialmente com valor ”dynamic”, este campo foi modificado no ambiente Off-Line para o valor ”static”. • AvailabilityStartTime: Quando @type=’dynamic’, este atributo deve estar presente. Neste caso, ele especifica a âncora para o cálculo dos primeiros momentos de disponibili- dade (em UTC) para qualquer segmento na apresentação de mídia. Para @type=“static” se presente, especifica o segmento hora de início da disponibilidade para todos os segmen- tos referidos neste MPD. Se não estiverem presentes, todos os segmentos descritos no MPD devem tornar-se disponíveis no momento em que o MPD estiver disponível. O codificador de vídeo Ateme configura este campo inicialmente com o horário em que o equipamento inicia a codificação do conteúdo de vídeo com referência ao UTC-0. Este campo foi apagado para realização dos testes no ambiente Off-Line. • PublishTime: Este campo especifica a hora em que o MPD foi gerado e publicado no servidor de origem, tendo sido apagado para realização dos testes no ambiente Off-Line. • MediaPresentationDuration: Este atributo especifica a duração de toda a apresen- tação de mídia. Se o atributo não está presente, a duração da apresentação na mídia é des- conhecido, devendo estar presente quando nem o atributo MPD@minimumUpdatePeriod nem o atributo Period@duration do último período estiverem presentes. Este campo foi adicionado com valor ”PT3M.13S” (duração ao conteúdo de vídeo de 3m e 13s) para realização dos testes no ambiente Off-Line. 90 • Period id: Uma apresentação de mídia consiste em um ou mais períodos. Um período é definido por um elemento de período no MPD. O campo ”Period id” especifica um identificador para este período. O identificador deve ser único no âmbito da apresentação de mídia. Se não estiver presente, nenhum identificador para o período é fornecido. O valor deste campo foi modificado do seu valor inicial de ”P0” para ”0” para realização dos testes no ambiente Off-Line. As modificações descritas anteriormente foram realizadas no arquivo manifest.mpd estão ilustradas nas Figuras 25 e 26, que exibem o arquivo original e o arquivo modificado respectivamente. Figura 25: Arquivo Manifest Original Fonte: Adaptado do Codificador de Vídeo Ateme Os campos marcados em amarelo (AvailabilityStartTime e PublishTime) na Figura 26 foram removidos do arquivo original. Os campos marcados em verde (Type e Period id), nas Figuras 25 e 26, são os campos que tiveram seus valores modificados em relação ao arquivo original e o campo marcado em cinza (MediaPresentationDuration), na Figura 26, foi adicionado no arquivo modificado. 91 Figura 26: Arquivo Manifest Modificado Fonte: Adaptado do Codificador de Vídeo Ateme 4.7 Analisador ROUTE/DASH A fim de avançar com os estudos offline de separação e transmissão dos conteúdos do BL e EL, é necessário melhor entender como o vídeo é fragmentado em segmentos ISO-BMFF, sinalizados e transportados pelo protocolo ROUTE/DASH contido dentro do fluxo UDP. Desta maneira, foi desenvolvido, em linguagem LUA (PUC-RIO, 2022), um analisador para o protocolo ROUTE/DASH (Vaz; Akamine, 2022b) baseado na norma ATSC A/331 (ATSC, 2022), a fim de ser utilizado no analisador de redes Wireshark (WIRESHARK, 2022). O datagrama UDP carrega pacotes LCT (IETF, 2022), os quais são utilizados pelo protocolo ROUTE/DASH afim de transportar os segmentos de A/V e arquivos XML de sinalização. O analisador LUA para o protocolo ROUTE/DASH (Vaz; Akamine, 2022b) identi- fica o protocolo utilizado para transportar o pacote desejado, juntamente com os campos e conteúdos, tais como: versão do protocolo LCT, sinalizador de controle de congesti- onamento (congestion control flag), CCI (Congestion Control Information - Informação de Controle de Congestionamento), TOI (Transport Object Identifier - Identificador de 92 Objeto de Transporte), TSI (Transport Session Identifier - Identificador de Sessão de Transporte), carga útil entre outros. Assim permitindo identificar o tipo de dados transportados, se de A/V ou sinalização, como a informação está fragmentada, onde começa um determinado conteúdo A/V, quan- tos pacotes são usados para transportar o conteúdo desejado, ou ainda se este conteúdo pertence ao BL ou ao EL. A Figura 27 ilustra a análise de um pacote ROUTE/DASH na saída do packager. A porção colorida em azul em seu topo informa características do pacote, tais como: a ordem de pacotes desta sequência, o instante de início de cada pacote, seu endereço IP de origem e destino, o protocolo de transporte de dados (se ROUTE/DASH ou UDP), seu comprimento total em bytes, porta utilizada e o comprimento útil (payload) em bytes. Neste caso, está selecionado o pacote Nº 1 desta sequência, com comprimento útil de 1420 bytes. A porção colorida em vermelho, localizada na parte intermediária Figura 27 realiza a análise do conteúdo deste pacote. Indicando informações como: o protocolo de enlace de dados utilizado (Ethernet), endereço IP de origem e destino deste pacote, a porta de transporte (6002) utilizada pela camada de transporte UDP. Na porção em vermelho, encontra-se ainda, a análise do pacote transportado pelo protocolo ROUTE/DASH. Nela observamos que o campo TSI assume o valor 101 (0x65), o que mostra, de acordo com as configurações deste set up, que é transportado conteúdo de vídeo que pertence ao EL. Além disso, observa-se que o campo TOI assume o valor 1, indicando que o conteúdo transportado pertence ao 1º segmento de vídeo. A porção colorida em verde, localizada na parte inferior da Figura 27 exibe o conteúdo total do pacote (cabeçalho e carga útil) no formato hexadecimal. 4.8 Extrator de Segmentos de Vídeo ISO-BMFF Contando com o suporte do analisador de protocolo ROUTE/DASH (Vaz; Akamine, 2022b) desenvolvido no âmbito desta tese, desenvolveu-se em plataforma Linux uma ro- tina C++, que recebe o fluxo de bits no formato UDP multicast do packager, extrai os 93 Figura 27: Análise de um Pacote ROUTE/DASH. Fonte: Adaptado do Analisador ROUTE/DASH. segmentos de vídeo do BL e do EL, nomeando-os de acordo com os nomes originais dos arquivos dado pelo codificador de vídeo em tempo real (Vaz; Akamine, 2022a), entregando os segmentos de vídeo do BL para a cadeia de transmissão OTA e realizando o upload dos segmentos de vídeo do EL para o CDN da Internet (Vaz et al., 2023a). Inicialmente a rotina C++ identifica os campos HDR_LEN (LCT Header Length - Comprimento do Cabeçalho LCT), Codepoint - Ponto de Código (CP), TSI, TOI, HEC (Header Extension Content - Conteúdo de Extensão do Cabeçalho), HEL (Header Ex- tension Length - Comprimento da Extensão do Cabeçalho) e HET (Header Extension Content - Conteúdo da Extensão do Cabeçalho) que são responsáveis por (ATSC, 2022), (DASH-IF, 2018), (IETF, 2022) e (IETF, 2024): • HDR_LEN: Exprime o comprimento total do cabeçalho LCT. Se possuir valor 0x08, indica que o cabeçalho total da camada LCT possui 36 bytes no total (extended header) ou 32 bytes contados a partir do término do campo CP. Se tiver valor 0x04, indica 94 que o cabeçalho total da camada LCT possui 20 bytes no total ou 16 bytes contados a partir do término do campo CP. • CP: Identificador utilizado para transmitir informações sobre a mídia que está sendo transportada dentro do pacote. Se tiver valor 0x00, indica que o protocolo LCT carrega arquivos XML, de acordo com as configurações deste set up. Caso assuma o valor 0x05, indica que o protocolo LCT carrega segmentos de inicialização e caso assuma o valor 0x08, indica que o protocolo LCT carrega arquivos de A/V. • TSI: Este campo, também denominado canal LCT, é utilizado para identificar unicamente a sessão de transporte acrshortROUTE/DASH. Se possuir valor 0x00, indica que é transportado um arquivo XML. Adicionalmente, de acordo com as configurações deste set up, se valor for 0x64 (100), identifica que o fragmento de vídeo transportado pertence ao BL e caso seja de valor 0x65 (101), identifica que o fragmento de vídeo transportado pertence ao EL. Caso assuma o valor 0xC8 (200), significa que o pacote transporta conteúdos de áudio. • TOI: Campo utilizado para indicar a qual objeto dentro da sessão este pacote pertence, seu valor indica a numeração (Number) do segmento de A/V (video-Bandwidth- Number.mp4v”) ao qual o fragmento pertence. Por ex. se o campo TOI tiver o valor de 0x02, indica que o fragmento pertence ao segmento número 2. • HEL e HEC: Quando o campo HDR_LEN assume valor 0x08, o campo HET assume valor 0x40 (64), indicando o primeiro fragmento de um segmento de A/V. Neste caso o campo HEL assume valor 0x04 indicando que no campo HEL são transportados dados de correção de erro. Este valores indicam que é transportado o primeiro fragmento de um segmento de A/V. De acordo com as configurações deste set up, quando o campo HDR_LEN assume valor 0x04, o campo HET assume valor 0x00, o campo HEL é concatenado com o campo HEC a fim de indicar a ordem do fragmento de A/V transportado. Esta estrutura é utilizada para indicar a ordem dos fragmentos de A/V transportados. Neste caso o campo HEL inicia-se sempre com o valor 0x00 e o campo HEC com o valor 0x0568 (1384) indicando o segundo fragmento de A/V. o A partir do terceiro fragmento o campo HEC é acrescido de 0x0578 (1400), seguindo portando a ordem: 95 - Segundo fragmento: HEL 0x00 HEC 0x0568. - Terceiro fragmento: HEL 0x00 HEC 0x0AE0. - Quarto fragmento: HEL 0x00 HEC 0x1058. - Quinto fragmento: HEL 0x00 HEC 0x15D0. e assim sucessivamente. Identificados os campos descritos anteriormente, são extraídos os arquivos originais do fluxo UDP multicast: manifest.mpd, video-2000000-init.mp4 (segmento de vídeo inicial do BL), video-2500000-init.mp4 (segmento de vídeo inicial do EL), bem como os segmentos de vídeo restantes do BL e do EL (Vaz et al., 2023a). As configurações adotadas neste set up para o codificador de vídeo em tempo real utilizam a seguinte regra de nomenclatura para os segmentos de vídeo: • Inicialização dos segmentos de vídeo: video-$Bandwidth$-init.mp4 (ATEME, 2020). Por ex.: - BL: video-2000000-init.mp4 - EL: video-2500000-init.mp4 • Segmentos de vídeo: video-$Bandwidth$-$Number$.mp4v, sendo que, a cada novo segmento de vídeo que é gerado pelo codificador de vídeo, o campo $Number$ é incremen- tado com valor 1. Por ex.: - BL: video-2000000-1.mp4 - BL: video-2000000-2.mp4 - EL: video-2500000-1.mp4 - EL: video-2500000-2.mp4 e assim sucessivamente. 96 4.9 Proposta do Arquivo Manifesto Além de extrair os segmentos de vídeo do fluxo UDP multicast, o extrator de seg- mentos de vídeo ISO BMFF substitui o arquivo manifest.mpd originalmente gerado pelo codificador de vídeo em tempo real um arquivo novo, o que permite transmissão/recepção híbrida, portanto, o receptor de DTV pode baixar o EL do CDN, combiná-lo e sincronizá- lo com o conteúdo do BL recebido pela transmissão OTA (Vaz et al., 2023a). A Figura 28 ilustra a estrutura do arquivo MPD proposto, onde o BL (v100) é trans- mitido via OTA, enquanto o EL (v101) é transmitido via Internet. Figura 28: Estrutura do Arquivo Manifest.MPD Proposto. (Vaz et al., 2023a) A Figura 29 ilustra o arquivo manifesto contendo as múltiplas URLs como fonte do BL e do EL. Ao passo que o BL é armazenado no servidor interno do receptor (através da URL http://192.168.0.3/linux - destacada em amarelo), o EL é baixado diretamente do CDN (através da URL https://radvaz.s3.sa-east-1.amazonaws.com/el/ - destacada em verde). Outro atributo do arquivo manifesto que deve ser destacado é o campo dependcyId, que possui valor ”dependcyId = Video1_1”e atribui a dependência do EL, identificado pelo campo ”id = Video1_2”, ao BL identificado pelo campo ”id = Video1_1”. No arquivo manifesto, foi mantida duração de aproximadamente 2 s do segmento de vídeo e do min buffer time, por ser a configuração padrão do codificados de vídeo ATEME. 97 Figura 29: Exemplo de Escrita do Arquivo Manifest.MPD Proposto. Autoria própria (2022). 4.10 Proposta da Arquitetura do Receptor A Figura 30 ilustra a arquitetura proposta para o receptor de DTV. Este é uma estação Desktop rodando o sistema operacional Windows 10, que possui um sintonizador ATSC 3.0 e que possui um servidor DASH interno, além de utilizar o reprodutor de vídeo GPAC. O receptor recebe o sinal de RF, extrai o conteúdo do BL, o armazenando no servidor interno do receptor. O reprodutor de vídeo GPAC reproduz o conteúdo do BL a partir do servidor interno do receptor, além de receber o conteúdo do EL armazenado na CDN, sincronizando ambas as camadas de vídeo, executando o enriquecimento de vídeo de FHD 2K para UHD 4K (Vaz et al., 2023a). 4.11 Testes Propostos A latência entre BL e o EL é um desafio do sistema. A CDN deve oferecer baixa latência para entregar o EL afim de permitir uma boa experiência do usuário (AWS, 98 Figura 30: Proposta de Arquitetura do Receptor (Vaz et al., 2023a) 2022b). Além disso, o receptor de DTV precisa receber ambos os conteúdos, armazená- los e sincronizá-los para reproduzi-los corretamente. Considerando o segmento de vídeo A de BL e EL, a latência de tempo entre eles pode ser calculada conforme a Equação (2): TLatencia = TEL − TBL (2) Onde, TBL o momento em que o segmento A de vídeo BL completo está disponível no receptor. TEL o momento em que o segmento A de vídeo EL completo está disponível no receptor. TLatencia é a diferença entre esses momentos. Desta maneira, alguns testes foram propostos e executados para medir a latência entre o BL e o EL durante sua transmissão e verificar o comportamento do receptor em diferentes condições. Estes são listados a seguir, juntamente com seus respectivos propósitos (Vaz et al., 2023a): 1. Receptor deve reproduzir o BL e EL armazenados no servidor interno do receptor. - Propósito: Avaliar se o receptor sincroniza corretamente o BL e o EL sem sofrer efeitos do transporte pela CDN. 99 2. Receptor deve reproduzir o BL armazenado no servidor interno do receptor e EL já carregado no CDN. - Propósito: Avaliar se o receptor sincroniza corretamente o BL e o EL com pequena latência adicionada entre ambas as camadas. 3. Receptor deve extrair o BL do sinal OTA, combiná-lo com o EL já carregado no CDN e reproduzi-los. - Propósito: Avaliar se o receptor extrai corretamente o BL do sinal OTA e sincroniza ambas as camadas considerando a latência adicionada entre elas. 4. Receptor deve reproduzir o BL armazenado no servidor interno do receptor e o EL carregado em tempo real para o CDN. - Propósito: Avaliar se o receptor sincroniza corretamente o BL e o EL considerando a latência adicionada entre ambas as camadas durante o processo de upload do EL. 5. Receptor deve extrair o BL do sinal OTA, combiná-lo com EL carregado em tempo real para o CDN. - Propósito: Avaliar se o receptor opera corretamente nas condições de recepção do usuário. 4.12 Resultado dos Testes O receptor proposto neste trabalho conseguiu receber adequadamente os conteúdos ROUTE/DASH, extrair os BL e EL do fluxo UDP multicast, sincronizá-los e reproduzir conteúdo de vídeo UHD 4K enriquecido em todos os testes propostos (Vaz et al., 2023a). Diferentes valores de latência entre o BL e o EL foram medidos para cada teste executado de acordo com os logs do GPAC (Feuvre; Concolato; Moissinac, 2007), (Feuvre, 2020). Conforme esperado, o EL está atrasado em relação ao BL devido às diferentes formas de transmissão utilizadas para transportá-los. O gráfico da Figura 31 ilustra como a latência entre o BL e o EL evolui de acordo com os testes 1 a 5, onde seu eixo horizontal (Eixo X) indica a qual segmento de vídeo o conjunto BL e EL se refere, ao passo que o seu eixo vertical (Eixo Y) indica o valor em ms da latência entre o BL e o EL para este segmento de vídeo. 100 A Tabela 3 mostra a latência média medida entre os BL e EL, além do o respectivo erro padrão para cada um dos testes realizados. Os Testes de 1 a 5 foram executados somente 2 vezes cada um, dado que a meta desta Tese é verificar como e em quais condições o video escalável pode ser transmitido de forma híbrida ao usuário final. Figura 31: Gráfico de Latência Entre o BL e o EL. (Vaz et al., 2023a) Tabela 3: Latência Média Entre o BL e o EL . Teste Executado Latência Média (ms) Teste l 229 ± 23 Teste 2 526 ± 66 Teste 3 457 ± 34 Teste 4 1301 ± 289 Teste 5 1240 ± 218 (Vaz et al., 2023a) Como esperado, o Teste 1 apresentou o menor valor de latência entre todos os tes- tes executados, pois o conteúdo de ambas camadas já estavam armazenados no servidor interno do receptor. 101 No Teste 2, a latência entre as duas camadas aumentou em relação ao Teste 1, como esperado. Neste teste, o EL, que já estava armazenado no CDN, precisava ser carregado para ser combinado com BL, já armazenado no servidor do receptor. A latência entre o BL e o EL diminuiu no Teste 3 (cerca de 69 ms), em relação ao Teste anterior. Neste caso, o receptor deve primeiramente receber e extrair o conteúdo do BL vindo pelo sinal OTA, somente então pôde requisitar o conteúdo do EL, previamente disponível no CDN, para combinar as duas camadas e reproduzi-las. No Teste 4, a latência entre as duas camadas aumentou (aproximadamente 844 ms), como esperado. O BL já estava armazenado no servidor do receptor, ao passo que o EL foi carregado para o CDN em tempo real durante transmissão de vídeo. A latência foi afetada pelo upload/download do EL e pela infraestrutura do CDN. No entanto, a latência introduzida pelo CDN (1301 ms) não afetou fortemente a experiência do usuário. No Teste 5, a latência entre o BL e o EL voltou a diminuiu em relação no Teste 4. Os motivos são semelhantes aos mencionado no Teste 3: O receptor deve primeiramente receber e extrair o BL vindo do sinal OTA, só então pôde solicitar os segmentos do EL. Como a velocidade de upload do EL para o CDN é alta, isso não afetou muito latência entre as duas camadas (Vaz et al., 2023a). A Figura 32 mostra a o enriquecimento da imagem de FHD 2K para UHD 4K feito pelo receptor. 4.13 Vantagens em Relação a Outras Implementações O tema de escalabilidade de vídeo e recepção híbrida IBB tem sido estudada pelo ETRI (Electronics and Telecommunications Research Institute - Instituto de Pesquisa em Telecomunicações e Eletrônicos) (Lee et al., 2020), (Yim et al., 2021), (You; Kim; Kim, 2021). Os autores de (Lee et al., 2020) utilizam a abordagem HPHT (High Power High Tower - Potência Alta Torre Alta), transmitindo sinal ATSC 3.0 LDM com SHVC. A camada superior do LDM contém vídeo do BL (720p@60), e a camada inferior do LDM contém vídeo do EL (2160p@60). A implementação utiliza o protocolo ROUTE/DASH e MPEG- DASH como camada de transporte para os sinal OTA e Internet. O sinal de RF de TV é 102 Figura 32: Vídeo enriquecido para UHD 4K pelo Receptor de DTV Fonte: Foto Tirada da Tela de Execução da Ferramenta GPAC. usado para consumo primário do serviço e o sinal de rede de banda larga pode ser usado para entregar fluxos alternativos de vídeo sempre que o sinal RF não estiver disponível. Em regiões onde apenas o sinal de TV RF está disponível, o receptor executa a comutação perfeita entre BL e BL+EL, de acordo com a disponibilidade do LDM do EL. Em regiões onde há baixa intensidade de sinal de TV e é detectada e o sinal 4G (4ª Geração) LTE estiver disponível, o receptor decodifica o BL vindo pelo sinal OTA, pois não é possível receber a partir do sinal OTA o conteúdo do EL devido à baixa intensidade do sinal de TV e solicita o conteúdo do EL via rede 4G rede. Finalmente, em regiões onde o sinal de TV não está disponível, o receptor muda para a rede de banda larga para decodificar o BL. Este estudo propõe uma implementação para executar a comutação redes OTA e Internet de acordo os parâmetros SNR e do RSSI (Received Signal Strength Indicator - Indicador de Força do Sinal Recebido) do sinal de TV registrados durante o movimento do receptor e de acordo com o a disponibilidade do sinal 4G. Os autores de (Yim et al., 2021) propõem a transmissão do serviço de vídeo 8K, porém retro-compatível com os receptores legados UHD 4K. O conteúdo UHD 4K (2160p@30) é transmitido como SHVC BL, utilizando os protocolos MMT ou ROUTE/DASH como 103 camada de transporte do sinal de TV , ao passo que o conteúdo UHD 8K (4320@30p) é transmitido como SHVC EL, utilizando o protocolo MPEG-DASH como camada de transporte, via Internet. À medida que a demanda por conteúdo UHD 8K aumenta, os aparelhos de TV UHD 4K podem se tornar obsoletos mais rapidamente. Portanto, este estudo propõe uma alternativa para estender a vida útil do aparelho de TV UHD 4K. Os autores de (You; Kim; Kim, 2021) propõem a utilização da escalabilidade de vídeo para oferecer mídia imersiva (3D) ao usuário final. Usando o recurso LDM ATSC 3.0, o sinal OTA transmite 2 PLPs, onde o PLP1 transporta o SHVC BL, que contém vídeo de visualização esquerda em HD. O PLP2 carrega o SHVC EL, contendo visão direita Vídeo UHD. De acordo com as coordenadas do arquivo MPD, o receptor é capaz de compilar as informações e oferecer uma imagem 3D ao usuário final. Entretanto, nos trabalhos (Lee et al., 2020) e (Yim et al., 2021) a latência entre o BL e o EL nos diferentes cenários de caso de uso não foram mostrados, nem a latência mínima que o receptor deve suportar para sincronizar ambas as camadas. Desta maneira, esta Tese tem algumas vantagens adicionais (Vaz et al., 2023a) consi- derando estas referências (Lee et al., 2020), (Yim et al., 2021): • Avaliação da latência entre os BL e EL causada pelo transporte do EL pelo CDN. • Sugerir a latência mínima entre o BL e o EL que o receptor de TV 3.0 precisa su- portar para reproduzir corretamente conteúdo de vídeo enriquecido com base nos cenários de teste descritos anteriormente. • Propor uma arquitetura de receptor, onde seja possível extrair os segmentos de vídeo do BL do sinal de RF de TV e armazená-los em um servidor local interno, onde outros receptores conectados à rede interna podem acessá-los, além de combinar com EL. 4.14 Avaliação da Qualidade de Vídeo No âmbito da literatura científica, diferentes métodos de análise de vídeo foram pro- postos para as mais variadas finalidades, podendo ser métodos objetivos ou subjetivos (REGIS, 2013), (Dumic; Grgic; Grgic, 2018) e (Ohm et al., 2012). 104 Métodos de análise objetiva são baseados em modelos matemáticos que aproximam os resultados da avaliação subjetiva da qualidade, na qual os observadores humanos são solicitados a avaliar a qualidade de um vídeo. Métricas objetivas avaliam grandezas, tais como PSNR (Peak Signal-to-Noise Ratio - Relação Sinal Ruído de Pico), MSE (Mean Squared Error - Erro Médio Quadrático), SSIM (Structural Similarity Index Measure - Medida do Índice de Similaridade Estrutu- ral), VMAF (Video Multimethod Assessment Fusion - Fusão de Avaliação Multimétodo de Vídeo), VQM (Video Quality Metric - Métrica de Qualidade de Vídeo), BDRate Bjontega- ard Delta Rate - Avaliação Delta de Bjontegaard (REGIS, 2013), (Bonnineau et al., 2020), através do uso de diferentes ferramentas de análises computacional, tais como: FFMPEG (Fast Forward Moving Picture Experts Group - Grupo de Especialistas em Quadros de Mo- vimento de Avanço Rápido) (BELLARD, 2024), Video Clarity (CLARITY, 2020), Elecard (ELECARD, 2020), AVISynth (SYNTH, 2020) entre outras. Qualidade subjetiva de vídeo é a qualidade do vídeo experimentada por seres huma- nos. Esta procura avaliar a forma como o vídeo é percebido pelo espectador (também chamado de ”observador”ou ”sujeito”) e designa sua opinião sobre uma sequência de vídeo específica. Testes subjetivos de qualidade de vídeo são experimentos psicofísicos nos quais vários espectadores classificam um determinado conjunto de estímulos. A medição da qualidade subjetiva do vídeo se mostra necessária, uma vez que algo- ritmos utilizados para avaliação objetiva da qualidade de vídeo, demonstraram correlação ruim com as classificações (REGIS, 2013), (Bonnineau et al., 2020). Embora a avaliação subjetiva da qualidade do vídeo seja considerada a maneira mais importante de avaliar um padrão de codificação de vídeo, dado que os seres humanos per- cebem a qualidade do vídeo subjetivamente (Ohm et al., 2012) e (Hoffmann et al., 2006), este método de avaliação seguindo as recomendações ITU-R (International Telecommu- nication Union - Radiocommunication Sector - União Internacional de Telecomunicações - Setor de Radiocomunicação) BT.500-14 (avaliação da qualidade de imagens e vídeos em televisão) (ITU-R, 2019) não foi utilizado nesta tese, a fim de evitar aglomerações de pessoas e evitar questões sanitárias referente ao COVID-19. 105 Desta maneira, propõem-se realizar diferentes medidas de qualidade objetiva de vídeo através da utilização da ferramenta FFMPEG, por ser uma ferramenta de uso gratuito e de uso amplamente disseminado na comunidade científica na parte de codificação e análise de vídeo (BELLARD, 2024), para avaliação da qualidade do conteúdo de vídeo recebido e reproduzido pelo receptor. Tem-se por objetivo a utilização da análise objetiva para comparar os conteúdos de vídeo recebido pelo BL (FHD 2K) com o conteúdo recebido pela composição dos BL e do EL (UHD 4K). Estas diferentes formas medidas são descritas a seguir. 4.15 Avaliação da Qualidade Objetiva de Vídeo A avaliação objetiva consiste em empregar modelos matemáticos para estimar a qua- lidade de uma sequência de vídeo ou de uma imagem automaticamente, isto é, sem ne- cessidade de avaliadores e de critérios subjetivos. As métricas objetivas podem ser classificadas segundo a sua filosofia de estimação da qualidade. Neste sentido, as principais métricas de dados e as métricas de imagem, descritas a seguir (REGIS, 2013). 4.15.1 Métrica de PSNR (Peak Signal-to-Noise Ratio - Relação Sinal Ruído de Pico) As medidas de qualidade objetiva de vídeo geralmente utilizam o MSE e o PSNR como métricas de fidelidade, sendo o PSNR a representação logarítmica do MSE (Dumic; Grgic; Grgic, 2018), (REGIS, 2013). O MSE é calculado a partir do valor médio dos erros quadráticos entre os pixels do vídeo original e do vídeo comprimido, sendo definido conforme a Equação (4): MSE = 1 NYX N∑ n=1 N∑ y=1 N∑ z=1 (f(x, y, n)− h(x, y, n))2 (3) Onde N é o número total de quadros, Y o número total de linhas e X o número total 106 de colunas no vídeo. As funções f(x,y,n) e h(x,y,n) representam as imagens de referência e imagem a ser comparada. As coordenada x, y e z são as coordenadas do pixel considerado da imagem. Quanto menor o valor do MSE, melhor é a qualidade do vídeo avaliado em relação ao original. O valor de MSE igual a zero significa que as amostras de vídeo submetidas à avaliação são idênticas. A PSNR é definida como definido conforme a Equação (4): PSNR = 10 log10 [ 2552 MSE ] (dB) (4) Quanto maior o valor do PSNR melhor a qualidade do vídeo avaliado em relação ao original. O valor de PSNR igual a infinito significa que as amostras de vídeo submetidas à avaliação são idênticas. Há várias razões para a popularidade destas duas métricas. As fórmulas para seu cálculo são simples de entender e implementar, além de ser de cálculo rápido. Apesar de sua popularidade, a PSNR tem apenas uma relação aproximada com a qualidade do vídeo percebido por observadores humanos, pois se baseia em uma comparação byte a byte dos dados, sem considerar o que realmente representam. Desta forma, a medida fornecida por essas métricas não apresenta uma boa correlação com a qualidade realmente percebida (Dumic; Grgic; Grgic, 2018), (REGIS, 2013). 4.15.2 Métrica SSIM (Structural Similarity Index Measure - Medida do Índice de Similaridade Estrutural) A métrica SSIM foi proposta com base no pressuposto de que o Sistema Visual Hu- mano é adaptado para extrair informações estruturais de imagens. Nesta métrica, os pixels possuem forte dependência entre si, aumentando consideravelmente de acordo com a proximidade entre eles. Supõe-se que essa dependência carrega informações importantes sobre a estrutura dos objetos na imagem e que quantificar a mudança estrutural de uma imagem pode fornecer uma boa aproximação para a qualidade percebida. A SSIM é calculada a partir de 3 comparações de medição de imagem: luminância, 107 contraste e estrutura. Cada uma dessas medidas é calculada na janela quadrada local 8x8 que se move pixel a pixel sobre toda a imagem. Em cada etapa, as estatísticas locais e o índice SSIM são calculados na janela local. Como o mapa de índice SSIM resultante geralmente exibe artefatos de ”blocagem” indesejáveis, cada janela é filtrada com função de ponderação gaussiana (11x11 pixels). Na prática, geralmente é necessária uma única medida de qualidade geral de toda a imagem, de modo que o índice SSIM médio - MSSIM (Mean Structural Similarity Index Measure - Medida do Índice de Similaridade Estrutural Média) - é calculado para avaliar a qualidade geral da imagem. A SSIM pode ser vista como uma medida de qualidade de uma das imagens comparadas, enquanto a outra imagem é considerada de qualidade perfeita. Pode dar resultados entre 0 e 1, onde 1 significa qualidade excelente e 0 significa qualidade ruim (Dumic; Grgic; Grgic, 2018), (REGIS, 2013). 4.15.3 Métrica VMAF (Video Multimethod Assessment Fusion - Fusão de Avalia- ção Multimétodo de Vídeo) O VMAF foi formulado pela empresa Netflix em Junho de 2016 para se correlacionar fortemente com as pontuações subjetivas do MOS. Usando técnicas de aprendizado de máquina, uma grande amostra de pontuações MOS foi usada como base para treinar um modelo de estimativa de qualidade. É uma métrica de qualidade de vídeo perceptual de referência completa que visa aproximar a percepção humana da qualidade do vídeo. Esta métrica concentra-se na degradação da qualidade devido à compressão e redimensiona- mento. VMAF estima a pontuação de qualidade percebida computando pontuações de vários algoritmos de avaliação de qualidade e fundindo-as usando uma SVM (Support Vec- tor Machine - Máquina de Vetores de Suporte). Atualmente, três métricas de fidelidade de imagem e um sinal temporal foram escolhidas como recursos para a SVM: 1. VIF (Visual Information Fidelity - Fidelidade de Informação Visual): Considera a perda de fidelidade de informação em quatro diferentes escalas espaciais. 2. DLM (Detail Loss Metric - Métrica de Perda de Detalhes): Mede a perda de detalhes e deficiências que distraem a atenção do espectador. 3. MCPD (Mean Co-Located Pixel Difference - Diferença Média de Ponto Co-localizado): 108 Mede a diferença temporal entre quadros na componente de luminância Estes recursos são combinados a fim de fornecer uma pontuação de saída única na faixa de 0 a 100 por quadro de vídeo, sendo 100 com qualidade idêntica à do vídeo de referência (R.Rassool, 2017). 4.16 Medidas da Qualidade Objetiva de Vídeo A fim de comparar objetivamente os conteúdos de vídeo recebidos pelo BL (FHD 2K) com o conteúdo recebido pela composição dos BL e do EL (UHD 4K), é necessário igualar a resolução de vídeo dos dois conteúdos em questão, uma vez que a ferramenta FFMPEG não realiza comparações de conteúdos de vídeo com resoluções diferentes (BELLARD, 2024), (LIU, 2020). Desta maneira, os conteúdos de vídeo recebidos foram ajustados através do FFMPEG da seguinte maneira: 1. Reduzindo-se a resolução de vídeo recebido pela composição dos BL e do EL (UHD 4K) para FHD 2K (resolução do BL) para comparação com o conteúdo de vídeo recebidos pelo BL. 2. Aumentando-se a resolução de vídeo recebido pelo BL (FHD 2K) para UHD 4K (resolução do conteúdo recebido pela composição dos BL e do EL) para comparação com o conteúdo de vídeo recebido pela composição dos BL e do EL. Os vídeos utilizados para realização das medidas de avaliação objetiva de vídeo pos- suem duração de 10 s cada um. Inicialmente, utilizou-se como fonte de vídeo o sinal original ISDB-Tb FHD 2K, pro- veniente do sintonia da novela, transmitida em horário nobre, em um STB (Set-Top Box - Caixa de Recepção de Sinal de Televisão) ISDB-Tb, que teve sua saída HDMI (High Definition Multimedia Interface - Interface Multimídia de Alta Definição) conectada ao codificador de vídeo ATEME. Desta maneira, o codificador ATEME codificou o sinal de vídeo para transmissão do BL e do EL, conforme set up experimental descrito na Figura 24. 109 Em seguida, gravou-se os segmentos de vídeo gerado pelo codificador de vídeo a fim de fazer as medidas de qualidade de vídeo objetivo através da ferramenta FFMEG, onde os resultados das medidas de PSNR, SSIM e VMAF são exibidos nas Tabela 4. Suas linhas representam os conteúdos de vídeos tratados conforme descrito nos itens 1 e 2 enumerados no início desta seção e suas colunas, da esquerda para direita, repre- sentam os conteúdos de vídeo utilizados para medida de qualidade objetiva, os resultados obtidos nas medidas de PSNR para luminância (PSNR-Y), crominância – complemento de azul (PSNR-U), crominância – complemento de vermelho (PSNR-V), PSNR médio, SSIM para luminância (SSIM-Y), crominância – complemento de azul (SSIM-U), cromi- nância – complemento de vermelho (SSIM-V), SSIM total, que representa a semelhança geral dos dois vídeos e o resultados obtidos nas medidas de VMAF. A fim de ter outros parâmetros de comparação de qualidade de vídeo objetiva, utilizou- se como fonte de vídeo um sinal nativo UHD 4K previamente gravado e codificado pelo codificador de vídeo ATEME para transmissão do BL e do EL, conforme set up experi- mental descrito na Figura 24, onde os resultados das medidas de PSNR, SSIM e VMAF obtidos via utilização da ferramenta FFMPEG são exibidos nas Tabela 5. As linhas da Tabelas 5 representam os conteúdos de vídeos tratados conforme descrito nos itens 1 e 2 enumerados no início desta seção. Suas linhas representam os conteúdos de vídeos tratados conforme descrito nos itens 1 e 2 enumerados no início desta seção e suas colunas, da esquerda para direita, repre- sentam os conteúdos de vídeo utilizados para medida de qualidade objetiva, os resultados obtidos nas medidas de PSNR para luminância (PSNR-Y), crominância – complemento de azul (PSNR-U), crominância – complemento de vermelho (PSNR-V), PSNR médio, SSIM para luminância (SSIM-Y), crominância – complemento de azul (SSIM-U), cromi- nância – complemento de vermelho (SSIM-V), SSIM total, que representa a semelhança geral dos dois vídeos e o resultados obtidos nas medidas de VMAF. A fim de se ter uma melhor sensibilidade entre os valores da medida de qualidade objetiva de imagem e sua percepção a Tabela 6 relaciona as faixas de qualidade de vídeo percebida com as respectivas faixas de medida objetiva. 110 Tabela 4: Avaliação da Qualidade Objetiva de Vídeo Si- nal ISDB-Tb Conteúdo de Vídeo PSNR- Y (dB) PSNR- U (dB) PSNR- V (dB) PSNR- Médio (dB) SSIM- Y SSIM- U SSIM- V SSIM- Total VMAF ISDB-Tb FHD 2K x ISDB-Tb UHD 4K ajustado 2K 29 44 43 31 0,9643 0,9832 0,9844 0,9708 71,1351 ISDB-Tb UHD 4K ajustado 2K x ISDB-Tb FHD 2K 29 44 44 31 0,9667 0,9863 0,9873 0,9734 73,9438 ISDB-Tb FHD 2K ajustado 4K x ISDB-Tb UHD 4K 29 44 43 31 0,9734 0,9880 0,9889 0,9784 66,9011 ISDB-Tb UHD 4K x ISDB-Tb FHD 2K ajustado 4K 29 44 44 31 0,9765 0,9912 0,9920 0,9815 74,6766 Autoria Própria (2024). 111 Tabela 5: Avaliação da Qualidade Objetiva de Vídeo Si- nal Original UHD 4K Conteúdo de Vídeo PSNR- Y (dB) PSNR- U (dB) PSNR- V (dB) PSNR- Médio (dB) SSIM- Y SSIM- U SSIM- V SSIM- Total VMAF Original UHD BL 2K x Original UHD 4K ajustado 2K 34 42 44 36 0,9204 0,9674 0,9784 0,9379 57,7509 Original UHD 4K ajustado 2K x Original UHD BL 2K 34 45 45 36 0,9227 0,9701 0,9813 0,9404 64,3732 Original UHD BL ajustado 4K x Original UHD 4K 34 42 44 35 0,9345 0,9742 0,9836 0,9493 37,3598 Original UHD 4K x Original UHD BL ajustado 4K 34 42 44 35 0,9376 0,9774 0,9897 0,9524 50,4459 Autoria Própria (2024). 112 Tabela 6: Percepção da Qualidade de Vídeo e Respecti- vas Faixas de Valores Objetivos Qualidade de Vídeo PSNR (dB) SSIM VMAF Excelente 38 ou superior 0,93 ou superior 90 ou superior Boa 35-38 0,88 - 0,93 74 - 90 Justa 33-35 0,84 - 0,88 58 - 74 Pobre 30-33 0,78 - 0,84 38 - 58 Ruim 33 ou inferior 0,78 ou inferior 38 ou inferior Fonte: Adaptado de (ELECARD, 2020). Verifica-se pelos resultados informados pela Tabela 4 que o valor médio da medida de PSNR-Médio é de 31 dB. Conforme os dados da Tabela 6, esta medida representa uma imagem de qualidade pobre, entretanto, o valor da medida de PSNR, quando considera- das as componentes de crominância, se tornam mais apreciáveis possuindo valor médio aproximado de 44 dB, o que é representa uma qualidade de imagem excelente de acordo com a Tabela 6. Percebe-se que por esta escala, as medidas de qualidade objetiva são muito mais expressivos na parte de crominância do que em valor médio ou em luminância. As medidas de SSIM informados pela Tabela 4 seguem uma dinâmica semelhante aos da medida de PSNR, de forma que os valores de qualidade objetiva na parte de crominância são superiores aos valores da parte de luminância. As medidas de SSIM-Total da Tabela 4 possuem valor médio aproximado do 0,97, o que é considerada uma qualidade de vídeo excelente de acordo com a Tabela 6. A medidas de VMAF da Tabela 4 possuem valor médio aproximado de 61 para as 2 primeiras linhas, que representam o caso em que reduziu-se a resolução de vídeo recebido pela composição dos BL e do EL (UHD 4K) para FHD 2K (resolução do BL). Neste caso, de acordo com a 6, a qualidade de vídeo é considerada justa. As duas últimas linhas da Tabela 4 possuem valor médio aproximado de VMAF de 70,8. O que de acordo com a Tabela 6, representa uma qualidade de vídeo justa. 113 Da mesma maneira que a Tabela 4, o valor médio da medida de PSNR-Médio infor- mado pela Tabela 5 é menor que o valor da medida de PSNR, quando consideradas as componentes de crominância. O valor médio aproximado da medida de PSNR-Médio é de 36 dB, o que de acordo com a Tabela 6, é considerada uma qualidade de imagem justa. O valor médio aproximado da medida de PSNR quando consideradas as componentes de crominância é de 44 dB, o que é representa uma qualidade de imagem excelente de acordo com a Tabela 6. O resultado da medida de PSNR-Médio informado pela a Tabela 5 é em média 5 dB mais elevado que o da Tabela 4. Enquanto na Tabela 4 o PSNR-Médio é de 31 dB, na Tabela 5 o PSNR-Médio é cerca de 36 dB. As medidas de SSIM informados pela Tabela 5 seguem uma dinâmica semelhante aos da medida de PSNR, de forma que os valores de qualidade objetiva na parte de crominância são superiores aos valores da parte de luminância. As medidas de SSIM-Total da Tabela 5 possuem valor médio aproximado do 0,94, o que é considerada uma qualidade de vídeo excelente de acordo com a Tabela 6. Este valor é inferior ao verificado na Tabela 4, que possui valor médio aproximado de 0,97. A medidas de VMAF da tabela 5 possuem valor médio aproximado de 61 para as 2 primeiras linhas, que representam o caso em que reduziu-se a resolução de vídeo recebido pela composição dos BL e do EL (UHD 4K) para FHD 2K (resolução do BL). Neste caso, de acordo com a 6, a qualidade de vídeo é considerada justa. As duas últimas linhas da Tabela 5 possuem valor médio aproximado de VMAF de 43,9. O que de acordo com a Tabela 6, representa uma qualidade de vídeo pobre. Para referência, as Figuras 33 e 34 mostram os conteúdos de vídeo transportados pelo BL (FHD 2K) do vídeo ISDB-Tb (UHD 4K) e pela composição BL + EL (UHD 4K) do vídeo ISDB-Tb (UHD 4K) respectivamente. Sutilmente, percebe-se que a qualidade de imagem do conteúdo de vídeo formado pela composição do BL + EL (UHD 4K) do vídeo ISDB-Tb (UHD 4K) - Figura 34 é ligeiramente melhor que a q qualidade da imagem transportada pelo BL (FHD 2K) do vídeo ISDB-Tb (UHD 4K) - Figura 33. Percebe-se de forma ligeiramente melhorada detalhes do cabelo do personagem, como 114 Figura 33: BL (FHD 2K) do vídeo ISDB-Tb (UHD 4K). Fonte: Foto Tirada da Tela de Execução da Ferramenta GPAC. Figura 34: BL + EL (UHD 4K) do vídeo ISDB-Tb (UHD 4K). Fonte: Foto Tirada da Tela de Execução da Ferramenta GPAC. a parte que está situada acima de sua orelha esquerda, ou do seu lado direito. Ou ainda, detalhes da camisa do personagem são ligeiramente melhor percebidos na Figura 34 do que na Figura 33. 115 A diferença de coloração entre as duas imagens são praticamente imperceptíveis, sendo a Figura 34 sutilmente mais vívida que a Figura 33. As Figuras 35 e 36 mostram os conteúdos de vídeo transportados pelo BL (FHD 2K) do vídeo original (UHD 4K) e pela composição BL + EL (UHD 4K) do vídeo ISDB-Tb (UHD 4K) respectivamente. Ao contrário do que foi ilustrado pelas Figuras 33 e 34, as diferenças ilustradas pelas Figuras 35 e 36 são bem mais acentuadas e perceptíveis. A diferença de coloração entre as imagens é facilmente perceptível, onde a coloração da Figura 36 é mais vívida, nítida e brilhante que a da Figura 35 Percebe com muito mais facilidade os detalhes da imagem da Figura 36 do que na Figura 35, como por exemplo as estrelas amarelas situadas na perna direita do calção preto do jogador com o copo de água (centro da tela). Ou ainda as estrelas amarelas posicionadas por sobre a faixa preta da camisa do mesmo jogador, situadas na altura do seu peito ao lado esquerdo. Percebe-se com maior nitidez os detalhes dos torcedores situados nas cadeiras do estádio (ao fundo da tela) na Figura 35 do que na Figura 34. Figura 35: BL (FHD 2K) do vídeo original (UHD 4K). Fonte: Foto Tirada da Tela de Execução da Ferramenta GPAC. 116 Figura 36: BL + EL (UHD 4K) do vídeo original (UHD 4K). Fonte: Foto Tirada da Tela de Execução da Ferramenta GPAC. 4.17 Considerações Finais Neste capítulo foi apresentado o tema desta tese, bem como a proposta de trabalho, descrevendo os equipamentos e insumos utilizados no ambiente experimental, procedi- mentos realizados, resultados alcançados e respectivas análises. 117 5 CONCLUSÕES No momento de escrita deste trabalho, a comunidade científica e industrial estava finalizando os testes de avaliação subjetiva da qualidade de vídeo para determinar a taxa de transmissão de vídeo mínima para transmitir o conteúdo FHD 1080p@60 para dimen- sionamento da camada física a ser utilizada na próxima geração de TV digital brasileira. O valor médio encontrado para transmissão de conteúdo de vídeo FHD 1080p@60 utilizando-se o padrão de compressão de vídeo MPEG-I - Parte 3/ ITU-T H.266 - VVC é de 7,5 Mbps. O relatório completo de todas as avaliações realizadas foi publicado pelo Fórum SBTVD ao final de Fevereiro de 2024 (SBTVD, 2024). Discute-se também quais as prioridades de requisitos a serem implementados na ca- mada de codificação de aplicação. Ademais, o Fórum SBTVD avança na elaboração das normas da TV 3.0. Espera-se ainda os resultados dos testes adicionais de avaliação da camada física, entre outros esforços de pesquisa e desenvolvimento para TV 3.0 iniciados em Janeiro de 2023. Neste contexto, esta tese aborda questões relacionadas com a utilização de vídeo escalável na nova geração de TV digital brasileira, também conhecida por TV 3.0, focando em sua utilização através da radiodifusão e através da Internet banda larga. A escalabilidade de vídeo é um recurso que permite que o mesmo conteúdo seja dis- tribuído por diferentes meios de comunicação com diferentes larguras de banda e/ou para receptores com diferentes capacidades de processamento e que pode oferecer diferentes vantagens à TV 3.0: • Oferecer o mesmo conteúdo com qualidade diferente para receptores de TV digital com capacidades diferentes. Um receptor de capacidade inferior pode decodificar a resolução do programa de 1080i@30 ou 1080p@60, enquanto um receptor de maior capacidade pode receber o mesmo programa com resolução melhorada de 2160p@60 e/ou 2160p@120. • Considerando o canal de RF 6 MHz utilizado no Brasil para transmissão do sinal de TV e o requisito de C/N <= 0 dB, espera-se que a taxa média de transmissão alcançada por uma configuração SISO seja de aproximadamente 2 Mbps, o que per- 118 mite, por ex., a transmissão de conteúdo pré-codificado 1080p@60. Para transmitir conteúdo de vídeo 2160p@60, seria necessário atingir uma taxa de transmissão de aproximadamente 8 Mbps, exigindo a combinação de técnicas de transmissão MIMO e channel bonding. • Outra maneira de fornecer conteúdos UHD 4K é transmitir a BL com conteúdo Full HD via radiodifusão e EL com enriquecimento de para UHD 4K via Internet de banda larga. • Mesmo se considerada uma região, onde apenas alguns canais RF estejam dispo- níveis, ainda é possível entregar conteúdo de programa de alta qualidade para o receptor. O programa básico pode ser transmitido como BL, para todos os recepto- res e a camada EL, pode ser fornecida via Internet, sem a necessidade de canal RF adicional para transmissão do EL, por ex., utilizando-se MIMO ou channel bonding. • Redução da largura de banda em comparação ao simulcasting de conteúdo. O programa básico é demandado em ambas as situações. Entretanto, não é necessário transmitir de forma independente o mesmo programa com resolução melhorada usando a largura de banda mais alta. Nesse caso, além da transmissão de BL, é necessário transmitir apenas o EL para decodificar o programa com maior qualidade de imagem, evitando assim o simulcasting, congestionamento da rede e reduzindo os tamanhos de armazenamento. • O conteúdo de elevada qualidade oferecido pela EL leva a uma realçada experiência do usuário em relação ao conteúdo base. A entrega de escalabilidade de vídeo utilizando transmissão híbrida proposta neste trabalho de pesquisa tem as seguintes contribuições em relação às demais relacionadas (SBTVD, 2024): 1. Este trabalho compensa o fato de que as tecnologias candidatas à TV 3.0 não foram testadas considerando os requisitos de transmissão híbrida, tais como: (a) Requisito TL1: Habilitar sincronização de dados e A/V transportados pela mesma ou em diferentes plataformas de distribuição mistas. 119 (b) Requisito TL2: Facilitar a retransmissão de conteúdo em diferentes platafor- mas de distribuição e para a rede doméstica. 2. O protocolo de camada de transporte utilizado ROUTE/DASH neste trabalho de pesquisa entrega com sucesso conteúdo de vídeo OTA/Internet (BL/EL). 3. Os resultados deste trabalho de pesquisa atendem aos requisitos de escalabilidade de vídeo e de transmissão híbrida da TV 3.0 (tais como como VC9, VC10, VC11, TL1 e TL2): (a) O requisito VC9 permite decodificação perfeita e alinhamento de A/V. (b) O requisito VC10 permite a interoperabilidade com diferentes plataformas de distribuição (transmissão híbrida). (c) O requisito VC11 permite a escalabilidade de vídeo. 4. Os experimentos construídos foram capazes de entregar conteúdos de vídeo UHD ao usuário final, aproveitando a infraestrutura de Internet fixa disponível no Brasil e atendendo ao requisito reuso-1 de frequência (C/N <= 0 dB) (PL2) da TV 3.0. 5. Os resultados mostram que é possível reduzir o custo do receptor de TV, uma vez que se demanda apenas uma interface de Internet Banda Larga e um sintonizador comum de RF DTV para receber vídeo UHD escalável. Ademais, as seguintes conclusões podem ser feitas face aos resultados alcançados e descritos anteriormente neste projeto: 1. O conceito de escalabilidade de vídeo está sendo estudado e padronizado por mais de 20 anos, entretanto nunca foi amplamente explorado em produtos comerciais devido à dificuldade de implementação e grandes diferenças de implementação entre codificação escalável e não escalável. Este obstáculo diminui com publicação do padrão SHVC que objetiva, entre outros pontos, a diminuição da complexidade de implementação, ao permitir o reaprovei- tamento de várias camadas simples do padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC (Boyce et al., 2016). 120 Os avanços realizados nos sistemas de TV digital e sua integração com a Internet cada vez mais intensa, particularmente observados no sistema ATSC 3.0, permitem a utilização de funcionalidades cada vez mais interessantes ao usuário, como a oferta de conteúdo de vídeo UHD e a utilização de vídeo escalável através do padrão SHVC para ofertar este tipo de conteúdo de vídeo. 2. A utilização do recurso de escalabilidade de vídeo pode trazer grandes benefícios a TV 3.0 conforme listado anteriormente. 3. Até o presente momento, o padrão SHVC é o mais avançado disponível comercial- mente para utilização em codificação em tempo real. 4. Neste trabalho, realizou-se a revisão da literatura científica com relação aos dife- rentes padrões de codificação de vídeo existentes e em desenvolvimento, bem como foram pesquisados e analisados os diferentes padrões de multiplexação de A/V exis- tentes e em desenvolvimento. 5. Neste trabalho, utilizando-se o codificador de vídeo ATEME Titan, realizou-se a co- dificação do conteúdo de vídeo utilizando-se o padrão SHVC, sendo o BL codificado com resolução de vídeo FHD 2K e o EL com resolução UHD 4K. 6. O BL foi transmitido via OTA utilizando o protocolo ROUTE/DASH como camada de transporte, ao passo que o EL foi transmitido via Internet, por meio de um CDN, utilizando o protocolo MPEG-DASH como camada de transporte. Ambos protocolos de camada de transporte já foram adotados pela TV 3.0. 7. O sincronismo entre os BL e EL é fundamental para permitir a montagem e exi- bição do conteúdo final. Estas coordenadas devem estar bem ajustadas no arquivo manifest.mpd. 8. A transmissão híbrida (OTA e Internet) dos BL e EL é factível, entretanto é neces- sário sinalizar adequadamente na camada de transporte o caminho de transmissão de cada uma e suas respectivas propriedades. Estas informações também devem ser ajustadas corretamente no arquivo manifest.mpd com suporte do equipamento multiplexador. 121 9. Diferentes tipos de testes foram propostos para medir a latência entre o BL e EL em diferentes cenários de transmissão do conteúdo de vídeo escalável ao usuário. 10. Em todos os testes executados nesta Tese, a latência medida entre BL e EL ficou abaixo de 1500 ms, sendo considerada uma boa latência para oferecer uma boa experiência ao usuário final. Em (AWS, 2022b), a AWS recomenda a utilização de sistema de baixa latência (2 s <= latência de vídeo <= 6 s) para distribuição de vídeo. 11. De acordo com os resultados alcançados nesta pesquisa, recomenda-se que os recep- tores da TV 3.0 com suporte ao vídeo escalável e à recepção híbrida suportem ao menos 2000 ms de latência entre o BL e o EL para enfrentar as instabilidades da rede e oferecer uma boa experiência de uso ao consumidor final. 12. Nos testes realizados nesta tese, não foram verificados casos de latência negativa (casos em que o EL estivesse disponível no receptor antes do BL). Isto se deve à algumas circunstâncias: A ferramenta GPAC primeiramente solicita um segmento do BL. Após este estar disponível para reprodução, ela solicita o respectivo segmento do EL. Ademais, utilizou-se no set-up somente um transmissor de sinal de TV, que transmite o sinal para um receptor que está localizado a cerca de 2 metros de distância do transmissor. Desta forma o sinal de TV transmitido via Internet sempre estará disponível no receptor depois do sinal OTA. Casos com diferente topografias de transmissão foram deixados para trabalhos futuros. 13. Avaliou-se subjetivamente a mudança de resolução espacial do conteúdo de vídeo básico - FHD 2K (1080p@30) para o enriquecido - UHD 4K (2160p@30) na recepção, além da avaliar objetivamente a mudança da qualidade de vídeo do conteúdo do BL para o conteúdo enriquecido, composto pelo BL + EL através de indicadores como VMAF, PSNR e SSIM. 14. Em todas avaliações foi possível verificar a melhoria da qualidade de imagem do vídeo enriquecido para o vídeo básico. 122 5.1 Atividades Realizadas Neste projeto de pesquisa foram realizadas as atividades listadas a seguir: 1. Revisão da literatura dos diferentes padrões de codificação de vídeo existentes; 2. Pesquisa e análise dos diferentes padrões de multiplexação de áudio e vídeo existen- tes e em desenvolvimento; 3. Montagem e configuração do ambiente experimental de transmissão e recepção de TV digital terrestre utilizando-se o sistema ATSC 3.0; 4. Transmissão e recepção do conteúdo de vídeo escalável via RF; 5. Testes Off-Line de transmissão do conteúdo de vídeo escalável via Internet. 6. Confecção de um analisador de protocolo ROUTE/DASH em linguagem LUA que utilizado sobre o analisador de redes Wireshark. 7. Confecção de uma rotina C++ que recebe o fluxo de bits no formato UDP multicast e extrai os segmentos de vídeo do BL e do EL, entregando-os para a cadeia de transmissão OTA e Internet respectivamente. 8. Propôs-se um arquivo manifesto (manifest.mpd) que permite ao receptor receber o conteúdo de vídeo do BL transmitido via OTA e o conteúdo de vídeo do EL transmitido via Internet. 9. Propôs-se uma arquitetura de receptor de DTV de acordo com os requisitos da TV 3.0, que permite a recepção do o conteúdo de vídeo do BL transmitido via OTA e do conteúdo de vídeo do EL transmitido via Internet. 10. Realização de testes para avaliação da latência entre os conteúdos de vídeo do BL e do EL em diferentes cenários de uso. 5.2 Trabalhos Futuros O seguintes horizontes abaixo são vislumbrados para continuação deste trabalho: 123 • Modificar a duração dos segmentos de vídeo e avaliar sua influência sobre latência entre as duas camadas de vídeo. • Explorar esta pesquisa utilizando uma velocidade de rede mais restritiva a fim de avaliar sua influência sobre latência entre as duas camadas de vídeo. • Outro cenário de teste que pode ser investigado é impor propositalmente maiores latência entre o BL e o EL a fim de verificar o comportamento do receptor e possíveis impactos na experiência do usuário. • Impor restrições a qualidade de serviço da rede como intermitência em seu funcio- namento, perda de pacotes, variações na velocidade de de conexão e verificar como estes fatores influenciam na experiência oferecida ao usuário. • A execução de provas de campo utilizando uma estação de radiodifusão e CDN comercial para medição da latência entre o EL e o BL em condições mais próximas as vivenciadas pelas emissoras de TV e pelos telespectadores (Vaz et al., 2023b). • A execução de provas de campo para medição exaustiva da latência entre o EL e o BL, executando-se cada um dos Testes de 1 a 5 diversas vezes a fim de determinar o intervalo de confiança das medidas encontradas. • A execução de provas utilizando-se diferente casos de topografia de transmissão do sinal OTA, como a aumentar consideravelmente a distância entre a antena transmissora e a recepção (por ex. para 10 ou 20 km), ou a utilização de do recurso de SFN pela rede transmissora e avaliar sua influência sobre latência entre as duas camadas de vídeo e sobre a experiência do usuário. • Utilizar o recurso de LDM dentro do sistema ATSC 3.0 para transmissão para transmissão de vídeo escalável e verificar possíveis impactos sobre a latência entre o BL e o EL, sobre o receptor e sobre a experiência do usuário. • Caso o recurso de LDM deseja adotado pela TV 3.0, pode-se repetir esta verificação utilizando este sistema. 124 5.3 Artigos Publicados Durante o desenvolvimento deste projeto de pesquisa, foram publicados oito artigos científicos, além de um artigo científico aceito em uma revista indexada conforme listados a seguir: • Revista Indexada 1. Título: Integrated Broadband Broadcast Video Scalability Usage Proposal to Next- Generation of Brazilian DTV Broadcasting System (TV 3.0) (Vaz et al., 2023a). (a) Autores: Rodrigo Admir Vaz, Luiz Gustavo Pacola Alves, Marcelo Lobeiro, Eric Ferraz, George Maranhão, Fadi Jerji e Cristiano Akamine. (b) Revista: Multmedia Tools and Applications. (c) Data: Outubro de 2023. (d) ISSN: 1573-7721. • Conferências 1. Título: Broadcast-Broadband Experience in ATSC 3.0: Proposal for Gamification and Complementary Cameras (AKAMINE et al., 2018). (a) Autores: Cristiano Akamine, Rafael Martins, Rodrigo Admir Vaz, André Go- doi, George Henrique Maranhão Garcia de Oliveira, Ricardo S. Rabaça, Uirá Moreno Rosário e Barros, Rafael Brancaccio, Daniel Ohata, José Roberto Ri- beiro, Cesar Diez, José Roberto Soares, Luiz Gustavo Pacola Alves, Fernando Polizini Del Nero, Gabriel Ferraresso, Leonardo Chaves e Pollyana Notargia- como. (b) Congresso: 2018 IEEE Broadcast Symposium (BTS). (c) Data: Outubro de 2018. (d) ISBN: 978-1-5386-5856-7. 2. Título: Multipath and Impulsive Noise Interference Testing Performance Compari- son Between Broadcast Systems: ISDB-TB and ATSC 3.0 (Oliveira et al., 2019). 125 (a) Autores: George Henrique Maranhão Garcia de Oliveira, Ricardo Seriacopi Ra- baça, Natalia Silva Santiago, Carlos Felipe Celestino Leonel, Matheus Andrade Santana, Victor Gabriel Rizzi Varela, Rodrigo Admir Vaz, Eric da Silva Ferraz, Rodrigo Ribeiro de Oliveira, Uirá Moreno Rosário e Barros, Leonardo Chaves, Gabriel Ferraresso, Leandro Pacheco, Julio Omi, Jae-Young Lee, Sung-Ik Park e Cristiano Akamine. (b) Congresso: 2019 IEEE International Symposium on Broadband Multimedia Systems and Broadcasting (BMSB). (c) Data: Junho de 2019. (d) ISBN: 978-1-5386-5855-0. 3. Título: Video Scalability Advantages for the Next Brazilian Terrestrial Digital Te- levision Generation (TV 3.0) (Vaz; Alves; Akamine, 2020). (a) Autores: Rodrigo Admir Vaz, Luiz Gustavo Pacola Alves e Cristiano Akamine. (b) Journal: SET International Journal of Broadcast Engineering. (c) Data: Dezembro de 2020. (d) ISBN: 2446-9432. 4. Título: Development of ROUTE/DASH Flow Analyzer (Santana et al., 2023). (a) Autores: Matheus Andrade Santana, George Henrique Maranhão Garcia de Oliveira, Allan Seiti Sassaqui Chaubet, Rodrigo Admir Vaz, Cristiano Akamine (b) Congresso: 2023 IEEE International Symposium on Broadband Multimedia Systems and Broadcasting (BMSB). (c) Data: Junho 2023. (d) ISBN: 978-1-5386-5855-0. 5. Título: Video Scalability Latency Tests for Brazilian TV 3.0 (Vaz et al., 2023b). (a) Autores: Rodrigo Admir Vaz, Thaise Alves da Silva, Luiz Gustavo Pacola Al- ves, Marcelo Lobeiro, Marcelo de Souza Colares, Allan Seiti Sassaqui Chaubet, George Henrique Maranhão Garcia de Oliveira, Cristiano Akamine. 126 (b) Congresso: 2023 IEEE Broadcast Symposium (BTS). (c) Data: Novembro de 2023. • Solo 1. Título: HDR10+ Concepts, Principles, Capabilities and Advantages for the Next- Generation of Brazilian Broadcasting System (TV 3.0) (TV 3.0) (Vaz; Alves; Lar- son, 2021). (a) Autores: Rodrigo Admir Vaz, Luiz Gustavo Pacola Alves e Steve Larson. (b) Journal: SET International Journal of Broadcast Engineering. (c) Data: Dezembro de 2021. (d) ISBN: 2446-9432. 2. Título: A Proposal to Apply SignWriting in IMSC1 Standard for the Next-Generation of Brazilian DTV Broadcasting System (Lobeiro; Vaz; Alves, 2022). (a) Marcelo Lobeiro, Rodrigo Admir Vaz, Luiz Gustavo Pacola Alves. (b) Congresso: 2023 WebMedia 2022. (c) Data: Novembro de 2022. (d) ISBN: 978-1-4503-9409-3. 3. Título: A Application Oriented Proposal to manage Scalable Video for the Next- Generation of Brazilian DTV Broadcasting System (Lobeiro; Vaz; Alves, 2023). (a) Marcelo Lobeiro, Rodrigo Admir Vaz, Luiz Gustavo Pacola Alves. (b) Congresso: 2023 WebMedia 2023. (c) Data: Outubro de 2023. (d) ISBN: 978-1-4503-9409-3. 127 6 ANEXO A título de referência, neste anexo são exibidas as figuras da interface de operação dos equipamentos e ferramentas utilizados nesta tese, conforme o set up ilustrado na na Figura 24. 1. Codificação de Vídeo • Ferramenta DigiCAP - PCAP Stream Generator. • Codificador de Vídeo ATEME Titan. 128 Figura 37: DigiCAP - PCAP Stream Generator. Fonte: Foto Tirada da Tela de Execução da Ferramenta PCAP Stream Generator. 2. Camada de Transporte • DigiCAP - Digicaster Multiplexer. • DigiCAP - Digicaster Scheduler. 129 Figura 38: Codificador de Vídeo ATEME Titan. Fonte: Foto Tirada da Interface de Operação do Codificador de Vídeo ATEME Titan. 3. Transmissão • Pro Television - Modulator. 130 Figura 39: DigiCAP - Digicaster Multiplexer. Fonte: Foto Tirada da Interface de Operação do Equipamento Digicaster Multiplexer. Figura 40: DigiCAP - Digicaster Scheduler. Fonte: Foto Tirada da Interface de Operação do Equipamento Digicaster Scheduler. 4. Recepção • Agos - IMAS (Integrated Measurement Analysis Software). 131 Figura 41: Pro Television - Modulator. Fonte: Foto Tirada da Interface de Operação do Equipamento Pro Television - Modulator. • Recepção do Vídeo Escalável Através da Ferramenta GPAC. 132 Figura 42: Agos - IMAS (Integrated Measurement Analysis Software). Fonte: Foto Tirada da Tela de Execução da Ferramenta Agos - IMAS (Integrated Measurement Analysis Software. Figura 43: Recepção do Vídeo Escalável Através da Ferramenta GPAC - BL (FHD) 2K - bitrate 2 Mbps. Fonte: Foto Tirada da Tela de Execução da Ferramenta GPAC. • Extrator dos Segmentos de Vídeo Concebido em C++. 5. Analisador de Transporte 133 Figura 44: Recepção do Vídeo Escalável Através da Ferramenta GPAC - BL+EL (UHD) 4K - bitrate 4.5 Mbps. Fonte: Foto Tirada da Tela de Execução da Ferramenta GPAC. Figura 45: Extrator dos Segmentos de Vídeo Concebido em C++. Fonte: Foto Tirada da Tela de Execução do Extrator dos Segmentos de Vídeo. • Kai Media - ATSC 3.0 Multi Player (Analyzer). 134 Figura 46: Kai Media - ATSC 3.0 Multi Player (Analyzer). Fonte: Foto Tirada da Tela de Execução da Ferramenta do Equipamento Kai Media - ATSC 3.0 Multi Player (Analyzer). Referências AGOS. IMAS - Intergrated Measurement Analysis System. Coréia do Sul: AGOS, 2020. Disponível em: . AKAMINE, C. et al. Broadcast-broadband experience in atsc 3.0: Proposal for gamification and complementary cameras. 2018 IEEE Broadcast Symposium (BTS), p. 1–6, Oct 2018. ANATEL, A. B. d. T. Painéis de Dados 2024. Brasil: [s.n.], 2024. Disponível em: . ATEME. TITAN Live. França: Ateme, 2020. Disponível em: . ATSC. A Compilation of Advanced Television Systems Committee Standards. Washington, DC: [s.n.], 2022. Disponível em: . AWS. AWS Cloud Computing Services. Estados Unidos: [s.n.], 2022. Disponível em: . 135 http://www.atsc.org/ AWS. Video Latency in Live Streaming. Estados Unidos: [s.n.], 2022. Disponível em: . Battista, S. et al. Overview of the low complexity enhancement video coding (lcevc) standard. IEEE Transactions on Circuits and Systems for Video Technology, v. 32, n. 11, p. 7983–7995, 2022. BELLARD, F. A complete, cross-platform solution to record, convert and stream audio and video. França: Fabrice Bellard, 2024. Disponível em: . BENOIT, H. Digital Television: Satellite, Cable, Terrestrial, IPTV, Mobile TV in the DVB Framework. Burlington: Ed. Elsevier, 2008. 304 p. ISBN 0240520815. BLEIDT, R. L. et al. Development of the mpeg-h tv audio system for atsc 3.0. IEEE Transactions on Broadcasting, v. 63, p. 202–236, Mar 2017. ISSN 0018-9316. Bonnineau, C. et al. Versatile video coding and super-resolution for efficient delivery of 8k video with 4k backward-compatibility. International Conference on Acoustics, Speech, and Signal Processing (ICASSP), May 2020. Boyce, J. M. et al. Overview of shvc: Scalable extensions of the high efficiency video coding standard. IEEE Transactions on Circuits and Systems for Video Technology, v. 26, p. 20–34, Jan 2016. ISSN 1051-8215. Bross, B. et al. Overview of the versatile video coding (vvc) standard and its applications. IEEE Transactions on Circuits and Systems for Video Technology, v. 31, n. 10, p. 3736–3764, 2021. ISSN 1051-8215. CHERNOCK, R. et al. Atsc 3.0 next generation digital tv standard — an overview and preview of the issue. IEEE Transactions on Broadcasting, p. 154–158, Mar 2016. ISSN 0018-9316. Choi, K. et al. An overview of the mpeg-5 essential video coding standard [standards in a nutshell]. IEEE Signal Processing Magazine, v. 37, p. 160–167, May 2020. ISSN 1558-0792. CIVIL, P. da R. C. Decreto Nº 11.484, de 6 de Abril de 2023. Brasil: [s.n.], 2023. Disponível em: . 136 http://www.planalto.gov.br/ccivil_03/_ato2023-2026/2023/decreto/D11484.htm http://www.planalto.gov.br/ccivil_03/_ato2023-2026/2023/decreto/D11484.htm CLARITY, V. ClearView – Visual Analyzer with Objective and Perceptual Quality Measurements. Estados Unidos: Video Clarity, 2020. Disponível em: . CLEVER_LOGIC. Receptor ATSC 3.0 de Referência. Coréia do Sul: Clever_Logic, 2020. Disponível em: . COMUNICAçõES, M. das. Portaria Nº 9.893, de 6 de Julho de 2023. Brasil: [s.n.], 2023. Disponível em: . DASH-IF. Guidelines for Implementation: DASH-IF Interoperability Points for ATSC 3.0, Version 1.1. Washington, DC: [s.n.], 2018. Disponível em: . DAVIDSON, G. A. et al. Atsc video and audio coding. Proceedings of the IEEE, v. 94, n. 1, p. 60–76, Jan 2006. ISSN 1558-2256. DIGICAP. Mux. Coréia do Sul: Digicap, 2020. Disponível em: . Domanski, M.; Mackowiak, S. Modified mpeg-2 video coders with efficient multi-layer scalability. Proceedings 2001 International Conference on Image Processing, v. 2, p. 1033–1036 vol.2, 2001. DTMB. Digital Television Terrestrial Multimedia Broadcasting - Frame structure, channel coding and modulation for digital television terrestrial broadcasting system - GB20600-2006. China: [s.n.], 2020. Disponível em: . Dumic, E.; Grgic, S.; Grgic, M. Comparison of hdtv formats by objective video quality measures. 2008 50th International Symposium ELMAR, v. 1, p. 1–4, Sep 2018. ISSN 1334-2630. DVB. Digital Video Broadcasting - A Guideline for the Use of DVB Specifications and Standards. France: [s.n.], 2020. Disponível em: . ELECARD. Video Quality Estimator. Estados Unidos: Video Clarity, 2020. Disponível em: . 137 http://www.cleverlogic.co.kr/ http://www.digicaps.com/solution/uhd-broadcasting-solution/mux/?lang=en http://www.digicaps.com/solution/uhd-broadcasting-solution/mux/?lang=en http://www.sac.gov.cn/ http://www.dvb.org/ ETSI. TS 103 433-1 - High-Performance Single Layer High Dynamic Range (HDR). V.1.2.1. Switzerland: [s.n.], 2017. Feuvre, J. L. Gpac filters. Proceedings of the 11th ACM Multimedia Systems Conference, p. 249–254, 2020. Feuvre, J. L.; Concolato, C.; Moissinac, J. C. Gpac: Open source multimedia framework. Proceedings of the 15th ACM International Conference on Multimedia, p. 1009–1012, 2007. FORUM, U. H. Ultra HD Forum. Estados Unidos: [s.n.], 2022. Disponível em: . GOMEZ-BARQUERO, D. et al. Mimo for atsc 3.0. IEEE Transactions on Broadcasting, v. 62, p. 298–305, Mar 2016. ISSN 0018-9316. GPAC. Video Player. França: GPAC Multimedia Open Source Project, 2020. Disponível em: . HBBTV. Hybrid Broadcast Broadband TV. Suíça: [s.n.], 2020. Disponível em: . HE, D. et al. System discovery and signaling transmission using bootstrap in atsc 3.0. IEEE Transactions on Broadcasting, v. 62, n. 1, p. 172–180, Mar 2016. ISSN 0018-9316. Hoffmann, H. et al. Studies on the bit rate requirements for a hdtv format with 1920 × 1080 pixel resolution, progressive scanning at 50 hz frame rate targeting large flat panel displays. IEEE Transactions on Broadcasting, v. 52, n. 4, p. 420–434, Dec 2006. ISSN 1557-9611. Hulusic, V. et al. Quality of experience in uhd-1 phase 2 television: The contribution of uhd+hfr technology. 2017 IEEE 19th International Workshop on Multimedia Signal Processing (MMSP), p. 1–6, Oct 2017. ISSN 2473-3628. IETF. Layered Coding Transport (LCT) Building Block - RFC 5651. Estados Unidos: [s.n.], 2022. Disponível em: . 138 IETF. Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE) - RFC 9223. Estados Unidos: [s.n.], 2024. Disponível em: . ISDB-T. Integrated Services Digital Broadcasting-Terrestrial - Association of Radio Industries and Business Receiver for Digital Broadcasting. Japan: [s.n.], 2020. Disponível em: . ISO/IEC. Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 1: Media presentation description and segment formats. 5. ed. Suíça: [s.n.], 2022. ITU-R. Recommendation ITU-R BT.2020-2. 3. ed. Suíça: [s.n.], 2015. Disponível em: . ITU-R. Recommendation ITU-R BT.709-6. 6. ed. Suíça: [s.n.], 2015. Disponível em: . ITU-R. Recommendation ITU-R BT.2100-2. 7. ed. Suíça: [s.n.], 2018. Disponível em: . ITU-R. Recommendation BT.500-14. 14. ed. Suíça: [s.n.], 2019. Disponível em: . JEONG, H. et al. Flexible and robust transmission for physical layer signaling of atsc 3.0. IEEE Transactions on Broadcasting, v. 62, n. 1, p. 204–215, Mar 2016. ISSN 0018-9316. JPEG. Joint Photographic Experts Group. Suíça: ISO/IEC, 2020. Disponível em: . JPEG, J. P. E. G. ISO/IEC 10918-2:1995 [ISO/IEC 10918-2:1995] Information technology — Digital compression and coding of continuous-tone still images: Compliance testing. Suíça: ISO/IEC, 1995. Disponível em: . KAI_MEDIA. Analizador MMT/Route. Coréia do Sul: Kai_Media, 2020. Disponível em: . KIM, K.-J. et al. Low-density parity-check codes for atsc 3.0. IEEE Transactions on Broadcasting, v. 62, n. 1, p. 189–196, Mar 2016. ISSN 0018-9316. 139 http://www.dibeg.org/ http://www.kai-media.com/ Lechner, B. J. et al. The atsc transport layer, including program and system information protocol (psip). Proceedings of the IEEE, v. 94, n. 1, p. 77–101, 2006. ISSN 0018-9219. Lee, J. Y. et al. Ip-based cooperative services using atsc 3.0 broadcast and broadband. IEEE Transactions on Broadcasting, v. 66, n. 2, p. 440–448, 2020. ISSN 1557-9611. Lim, Y. et al. Mmt: An emerging mpeg standard for multimedia delivery over the internet. IEEE MultiMedia, v. 20, n. 1, p. 80–85, 2013. ISSN 1941-0166. LIU, J. J. A practical guide for VMAF. Estados Unidos: Medium, 2020. Disponível em: . Lobeiro, M.; Vaz, R. A.; Alves, L. G. P. A proposal to apply signwriting in imsc1 standard for the next-generation of brazilian dtv broadcasting system. WebMedia 2022, p. 230–233, Nov 2022. Lobeiro, M.; Vaz, R. A.; Alves, L. G. P. Application oriented proposal to manage scalable video for the next-generation of brazilian dtv broadcasting system. WebMedia 2023, p. 230–233, Out 2023. LOGHIN, N. S. et al. Non-uniform constellations for atsc 3.0. IEEE Transactions on Broadcasting, v. 62, n. 1, p. 197–203, Mar 2016. ISSN 0018-9316. MCCANN, K. Mpeg-5 essential video coding (evc). ITU Workshop on The Future of Media, October 2019. Mochida, Y. et al. An mmt module for 4k/120fps temporally scalable video. 2019 IEEE International Symposium on Circuits and Systems (ISCAS), p. 1–5, May 2019. ISSN 2158-1525. MPEG, M. P. E. G. ISO/IEC 11172-2:1993 [ISO/IEC 11172-2:1993] Information technology — Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s — Part 2: Video. Suíça: ISO/IEC, 1993. Disponível em: . MPEG, M. P. E. G. ISO/IEC 14496-12:2022 - Information technology — Coding of audio-visual objects — Part 12: ISO base media file format. Suíça: ISO/IEC, 2022. Disponível em: . 140 Ogura, T.; Espinosa, P. 4k hdr workflow: from capture to display. 2018 IEEE Broadcast Symposium (BTS), Oct 2018. Ohm, J. et al. Comparison of the coding efficiency of video coding standards—including high efficiency video coding (hevc). IEEE Transactions on Circuits and Systems for Video Technology, v. 22, n. 12, p. 1669–1684, Oct 2012. ISSN 1051-8215. Oliveira, G. H. M. G. d. et al. Multipath and impulsive noise interference testing performance comparison between broadcast systems: Isdb-tb and atsc 3.0. 2019 IEEE International Symposium on Broadband Multimedia Systems and Broadcasting (BMSB), p. 1–5, Jun 2019. PARK, K.; LIM, Y.; SUH, D. Y. Delivery of atsc 3.0 services with mpeg media transport standard considering redistribution in mpeg-2 ts format. IEEE Transactions on Broadcasting, v. 62, p. 338–351, Mar 2016. ISSN 0018-9316. PROTELEVISION. Exciter. Dinamarca: ProTelevision, 2020. Disponível em: . PUC-RIO. LUA Programming Language. Brasil: PUC-Rio, 2022. Disponível em: . RAO, K. R.; DOMINGUEZ, H. O. Versatile Video Coding: Latest Advances in Video Coding Standards. São Paulo: River Publishers, 2019. 350 p. ISBN 8770220476. REGIS, C. D. M. Métrica de Avaliação Objetiva de Vídeo Usando a Informação Espacial, a Temporal e a Disparidade. 157 p. Tese (Doutorado) — Universidade Federal de Campina Grande, Campina Grande, 2013. Disponível em: . REGUEIRO, C. et al. Shvc and ldm techniques for hd/uhd tv indoor reception. 2015 IEEE International Symposium on Broadband Multimedia Systems and Broadcasting, Jun 2015. ISSN 2155-5044. RICHARDSON, I. E. G. H.264 and MPEG‐4 Video Compression. New York: Ed. Jonh Wiley and Sons, 2003. 281 p. ISBN 9780470848371. 141 http://dspace.sti.ufcg.edu.br:8080/jspui/handle/riufcg/8616 http://dspace.sti.ufcg.edu.br:8080/jspui/handle/riufcg/8616 RIEDMILLER, J. et al. Delivering scalable audio experiences using ac-4. IEEE Transactions on Broadcasting, v. 63, p. 179–201, Mar 2017. ISSN 0018-9316. R.Rassool. Vmaf reproducibility: Validating a perceptual practical video quality metric. 2017 IEEE International Symposium on Broadband Multimedia Systems and Broadcasting (BMSB), p. 1–2, June 2017. ISSN 2155-5052. SAITO, S. et al. 8k terrestrial transmission field tests using dual-polarized mimo and higher-order modulation ofdm. IEEE Transactions on Broadcasting, v. 62, p. 306–315, Mar 2016. ISSN 0018-9316. Santana, M. A. et al. Development of route/dash flow analyzer. 2023 IEEE International Symposium on Broadband Multimedia Systems and Broadcasting (BMSB), p. 1–5, Jun 2023. SBTVD. Fórum do sistema Brasileiro de TV Digital Terrestre. Brasil: [s.n.], 2023. Disponível em: . SBTVD. TV 3.0 CfP Phase 2 / Testing and Evaluation. Brasil: [s.n.], 2024. Disponível em: . Schwarz, H.; Marpe, D.; Wiegand, T. Overview of the scalable video coding extension of the h.264/avc standard. IEEE Transactions on Circuits and Systems for Video Technology, v. 17, n. 9, p. 1103–1120, Sep 2007. ISSN 1558-2205. Stadelmeier, L. et al. Channel bonding for atsc3.0. IEEE Transactions on Broadcasting, v. 62, p. 289–297, Mar 2016. ISSN 0018-9316. STOLFI, G. Notas de aula do Prof. Guido Stolfi. São Paulo: EPUSP, 2020. Disponível em: . Sullivan, G. J. et al. Standardized extensions of high efficiency video coding (hevc). IEEE Journal of Selected Topics in Signal Processing, v. 7, n. 6, p. 1001–1016, Dec 2013. ISSN 1941-0484. SYNTH, A. Video Post-Production Tool. Estados Unidos: AVI Synth, 2020. Disponível em: . 142 http://www.lcs.poli.usp.br/~gstolfi/ http://avisynth.nl/index.php/Main_Page TAN, T. K. et al. HEVC verification test report. Valencia: JCTVC-Q1011, 2014. Disponível em: . TEAMCAST, A. e. ATSC 3.0 Offers New and Flexible OTA Delivery Options for Broadcasters. Estados Unidos: Ateme e TeamCast, 2018. Disponível em: . TEAMCAST ATEME, B. M. S. T. e. S. NAB Show Demo To Show Power of SHVC Encoding in ATSC 3.0 Ecosystem. Estados Unidos: NAB, 2018. Disponível em: . Vaz, R. A.; Akamine, C. C++ A/V Segs Extractor. Brasil: R. A. Vaz and C. Akamine, 2022. Disponível em: . Vaz, R. A.; Akamine, C. Lua Dissector for ROUTE Protocol ATSC 3.0. Brasil: R. A. Vaz and C. Akamine, 2022. Disponível em: . Vaz, R. A.; Alves, L. G. P.; Akamine, C. Video scalability advantages for the next brazilian terrestrial digital television generation (tv 3.0). SET International Journal of Broadcast Engineering, Dec 2020. Vaz, R. A.; Alves, L. G. P.; Larson, S. Hdr10+ concepts, principles, capabilities and advantages for the next-generation of brazilian broadcasting system (tv 3.0). SET International Journal of Broadcast Engineering, Dec 2021. Vaz, R. A. et al. Integrated broadband broadcast video scalability usage proposal to next-generation of brazilian dtv broadcasting system. Multimedia Tools and Applications, Out 2023. ISSN 1573-7721. Vaz, R. A. et al. Video scalability latency tests for brazilian tv 3.0. 2023 IEEE Broadcast Symposium (BTS), p. 1–6, Nov 2023. 143 http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=9089 http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=9089 VCEG, V. C. E. G. Information Technology – Generic coding of moving pictures and associated audio information: Video. Suíça: ITU-T, 1995. Disponível em: . WALKER, G. K. et al. Route/dash ip streaming-based system for delivery of broadcast, broadband, and hybrid services. IEEE Transactions on Broadcasting, v. 62, p. 328–337, Mar 2016. ISSN 0018-9316. WEBDAV. WebDAV. Estados Unidos: WebDAV Resources, 2020. Disponível em: . Wien, M.; Ohm, J. Trends and recent developments in video coding standardization. IEEE International Conference on Multimedia and Expo (ICME), July 2018. Disponível em: . WIRESHARK. Wireshark Packet Analyzer. Estados Unidos: Wireshark, 2022. Disponível em: . WU, Y. et al. Overview of digital television development worldwide. Proceedings of the IEEE, v. 94, p. 08–21, Jan 2006. ISSN 0018-9219. Yim, H. J. et al. 8k-uhd service platform using shvc for atsc 3.0-based terrestrial broadcasting. 2021 IEEE International Symposium on Broadband Multimedia Systems and Broadcasting (BMSB), p. 1–3, 2021. ISSN 2155-5052. You, D.; Kim, S. H.; Kim, D. H. Atsc 3.0 route/dash signaling for immersive media: New perspectives and examples. IEEE Access, v. 9, p. 164503–164509, 2021. ISSN 2169-3536. ZHANG, L. et al. Layered-division-multiplexing: Theory and practice. IEEE Transactions on Broadcasting, v. 62, p. 216–232, Mar 2016. ISSN 0018-9316. 144 http://www.webdav.org/ http://www.icme2018.org/conf_tutorials INTRODUÇÃO Justificativa Objetivos Objetivo Geral Objetivos Específicos Metodologia Adotada nesta Tese Estrutura da Tese CODIFICAÇÃO DE VÍDEO Introdução Escalabilidade de Vídeo Formatos de Codificação de Vídeo ITU/ISO/IEC Padrão JPEG ou JPG Padrão MPEG-1 - Parte 2 Padrão MPEG-2 – Parte 2/ITU-T H.262 Padrão MPEG-4 - Parte 2 Padrão MPEG-4 - Parte 10/ITU-T H264 - AVC Padrão MPEG-H - Parte 2/ITU-T H.265 - HEVC MPEG-I - Parte 3/ITU-T H.266 - VVC MPEG-5 - Parte 1 - EVC MPEG-5 - Parte 2 - LCEVC Considerações Finais CAMADA DE TRANSPORTE Introdução Formatos Contêineres ISO/IEC MPEG-2 - Parte 1 - TS (TS) MPEG-4 - Parte 12 - ISO BMFF (BMFF) MPEG-H - Parte 1 - MMT (MMT) Formatos Contêineres ATSC 3.0 ROUTE/DASH Considerações Finais USO DO SISTEMA ATSC 3.0 PARA MEDIÇÃO DE LATÊNCIA DE VÍDEO ENTRE BROADCAST E BROADBAND COMO CONTRIBUIÇÃO PARA A PRÓXIMA GERAÇÃO DE TV DIGITAL TERRESTRE BRASILEIRA Introdução ATSC – Advanced Television Standard Comitte Transição para o Sistema ATSC 3.0 Propostas e Estudos em Direção à Próxima Geração de TV Digital Brasileira Ambiente Experimental Transmissão do Conteúdo de Vídeo Escalável Recepção do Conteúdo de Vídeo Escalável Estudo Off-Line para Transmissão do BL e do EL por Meios Distintos Analisador ROUTE/DASH Extrator de Segmentos de Vídeo ISO-BMFF Proposta do Arquivo Manifesto Proposta da Arquitetura do Receptor Testes Propostos Resultado dos Testes Vantagens em Relação a Outras Implementações Avaliação da Qualidade de Vídeo Avaliação da Qualidade Objetiva de Vídeo Métrica de PSNR (PSNR) Métrica SSIM (SSIM) Métrica VMAF (VMAF) Medidas da Qualidade Objetiva de Vídeo Considerações Finais CONCLUSÕES Atividades Realizadas Trabalhos Futuros Artigos Publicados ANEXO REFERÊNCIAS BIBLIOGRÁFICAS