UNIVERSIDADE PRESBITERIANA MACKENZIE ENGENHARIA ELÉTRICA. Uirá Moreno Rosário e Barros DYNAMIC ADAPTIVE STREAMING OVER HTTP FIXAS E VARIÁVEIS

Transcrição

1 UNIVERSIDADE PRESBITERIANA MACKENZIE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA Uirá Moreno Rosário e Barros DYNAMIC ADAPTIVE STREAMING OVER HTTP (DASH): CONCEITOS E REPRODUÇÃO EM BANDAS FIXAS E VARIÁVEIS São Paulo 2013

2 UNIVERSIDADE PRESBITERIANA MACKENZIE PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA Uirá Moreno Rosário e Barros DYNAMIC ADAPTIVE STREAMING OVER HTTP (DASH): CONCEITOS E REPRODUÇÃO EM BANDAS FIXAS E VARIÁVEIS Dissertação submetida ao Programa de Pós-Graduação em Engenharia Elétrica da Universidade Presbiteriana Mackenzie como parte dos requisitos para obtenção do título em Mestre em Engenharia Elétrica. Orientador: Professor Doutor Gunnar Bedicks Junior São Paulo 2013

3 B277d Barros, Uirá Moreno Rosário e Dynamic Adaptive Streaming Over Http (DASH): conceitos e reprodução em bandas fixas e variáveis. / Uirá Moreno Rosário e Barros São Paulo, f.: il.; 30 cm. Dissertação (Programa de Pós-Graduação (Stricto Sensu) em Engenharia Elétrica) - Universidade Presbiteriana Mackenzie - São Paulo, Orientador: Prof. Dr. Gunnar Bedicks Junior Bibliografia: f DASH. 2. Streaming. 3. IP. 4. Redes de computadores. 5. Android. 6. ISDB-Tb. I. Título. CDD

4 Ao Professor Fujio Yamada (in memoriam).

5 AGRADECIMENTOS Primeiramente agradeço a Deus, pela vida, pelo discernimento e pela oportunidade de estudo, assim como Sua presença em minha caminhada. Ao meu orientador, Professor Doutor Gunnar Bedicks, por ter acreditado e suportado minha pesquisa, pelo diálogo e suporte durante o mestrado. Também por ter me envolvido em atividades do laboratório relacionadas ao meu estudo, trazendo equipamentos e casos reais para que eu pudesse estudá-los. Fato esse que aproximou a realidade do mercado em meu trabalho e foi muito importante para o conhecimento adquirido, balanceado entre pesquisa e aplicação. Ao professor Daniel Arndt Alves que deu todo o apoio relacionado à computação, que foi essencial para a realização dos testes e resolução das dúvidas sobre redes. Ao professor Cristiano Akamine, pelas ótimas conversas, amizade e suporte nesse período. Aos meus colegas do Laboratório de TV Digital do Mackenzie: aos mestrandos pesquisadores pelo compartilhamento da vivência na elaboração de uma dissertação e grande ajuda na realização dos testes; à toda a equipe de professores, engenheiros, pesquisadores e administradores que ajudaram a sanar minhas dúvidas e foram muito importantes na construção do conhecimento sobre TV adquirido nos últimos anos. Essa convivência trouxe um significativo complemento na rotina e conhecimento durante o mestrado. Aos docentes do Programa de Pós Graduação em Engenharia Elétrica da Universidade Presbiteriana Mackenzie, pelas disciplinas lecionadas, que ajudaram no desenvolvimento da pesquisa, e pela disponibilidade em momentos de dúvidas. À minha namorada, Nathália Cunha, pela compreensão, apoio, carinho e companheirismo, mesmo em momentos de ausência. À minha família, que sempre suportou meus estudos, me incentivando e fazendo todo o possível para que eu conseguisse realizar a pesquisa. Ao Laboratório de TV Digital da Universidade Presbiteriana Mackenzie, pela bolsa de pesquisa e por disponibilizar todos os materiais utilizados, que viabilizaram a elaboração desta dissertação. Aos aportes do Programa CAPES RH-TVD, FINEP, CNPq e MACKPesquisa que foram importantes para a disponibilidade dos equipamentos presentes no Laboratório. iv

6 Have you heard - Pat Metheny

7 RESUMO Esta dissertação apresenta os conceitos, etapas e testes para o streaming IP de conteúdos de vídeo no sistema Dynamic Adaptive Streaming over HTTP (DASH). Toma-se essa tecnologia pois ela traz uma padronização do streaming HTTP, proposta pelo Moving Picture Experts Group (MPEG) e pelo International Organization for Standardization (ISO), com a ISO/IEC :2012. Primeiramente, é esclarecido o novo cenário de distribuição de conteúdos multimídia e seus desafios. Depois é apresentada a tecnologia DASH, com seu histórico e estruturação técnica. Também são explicados e exemplificados os conceitos de redes com base nos protocolos utilizados pelo DASH. Por fim, apresenta-se os testes práticos do DASH aplicado na distribuição de conteúdos televisivos em redes IP e sua reprodução em um dispositivo Mini-PC Android. O ensaio realizado em laboratório analisa a demanda de banda para reprodução do DASH codificado em constant bit rate (CBR) e adaptive bit rate (ABR) para limitações de banda de tráfego fixas e variáveis. Com os testes foi possível encontrar padrões de comportamento do DASH para as situações descritas. Palavras-chave: DASH, streaming, IP, rede de computadores, Android, ISDB-T B. vi

8 ABSTRACT This master thesis presents the concepts, steps and tests to stream a video content in a system called Dynamic Adaptive Streaming over HTTP (DASH). This technology is taken because it is a standardization of HTTP streaming, proposed by the Moving Picture Experts Group (MPEG) and International Organization for Standardization (ISO), with the ISO/IEC :2012 publication. Firstly, the new scenario of distributing multimedia content and his challenges are discussed. After this, the DASH technology is introduced with an historical and technical approach. Also, the network theory is explained following the protocols used by DASH. Lastly, the DASH practical tests are presented, focusing on the television contents distribution inside IP networks and it reproduction in an Mini-PC Android device. The tests analyses the network bandwidth demand for DASH reproduction coded for constant bit rate (CBR) and adaptive bit rate (ABR) with fixed and variable limitations on network bandwidth traffic. It was possible, with the tests, to find DASH behavior patterns to the situations described. Keywords: DASH, streaming, IP, computer networks, Android, ISDB-T B. vii

9 Lista de figuras Figura 1 Fluxo do sistema ISDB-T B Figura 2 Os quatro estágios do streaming Figura 3 Sistema de Comunicação de Shannon Figura 4 Transmissão simultânea de dois arquivos Figura 5 Assinaturas de Banda Larga Fixa (%) em relação ao desenvolvimento do país, Figura 6 Tempo de navegação de Internet por Velocidade de Conexão Figura 7 Comparativo da quantidade de assinaturas de Internet em banda larga fixa entre 2003 e Figura 8 Audiência de Internet por Velocidade de Conexão Figura 9 Composição do tráfego de Internet no período de pico para a América Latina e em acessos fixos Figura 10 Empacotamento ES no PES Figura 11 Método de inserção do PES no TS Figura 12 Método de multiplexação do TS Figura 13 Sistema de multiplexação do MPEG-2 Systems Figura 14 Estrutura do box MP Figura 15 Diagrama de estrutura do pacote mp Figura 16 Escopo da norma ISO/IEC : Figura 17 Hierarquia da MPD pela ISO/IEC : Figura 18 Diagrama de blocos do DASH Figura 19 Comparativo dos blocos ISDB-T B com o streaming Figura 20 Camadas do modelo OSI Figura 21 Comparação entre camadas do modelo OSI e TCP/IP Figura 22 Atribuição dos bits para classes de endereçamento IP Figura 23 Roteamento entre duas redes IP Figura 24 Distribuição dos bits do cabeçalho do datagrama IP Figura 25 Estrutura do datagrama IP Figura 26 Distribuição dos bits do cabeçalho do segmento UDP Figura 27 Distribuição dos bits do cabeçalho do segmento TCP Figura 28 Número de sequência do TCP Figura 29 Dinâmica da janela do TCP Figura 30 Abertura da conexão TCP

10 Figura 31 Exemplo de distribuição dos bits do cabeçalho do segmento TCP Figura 32 Fechamento da conexão TCP Figura 33 Estrutura pacote TCP/IP Figura 34 Conexão não persistente Figura 35 Conexão persistente com solicitações sequenciais Figura 36 Conexão persistente com solicitações em pipeline Figura 37 Formato da mensagem de requisição HTTP Figura 38 Formato da mensagem de resposta HTTP Figura 39 Distribuição dos bits do cabeçalho RTP Figura 40 Exemplo de distribuição dos bits do cabeçalho RTP Figura 41 Operação RTSP com RTP/RTCP e HTTP Figura 42 ZP1-20,02 ciclos/rad Figura 43 ZP2-160,18 ciclos/rad Figura 44 Setup de testes Figura 45 Quadro da sequência V Eighth Ave 1920x1088p30-8ave Figura 46 GK Figura 47 Variação da banda disponível - Padrão Decrescente Figura 48 Variação da banda disponível - Padrão Crescente Figura 49 Variação da banda disponível - Padrão Limites Alternados - início 8 Mbps Figura 50 Variação da banda disponível - Padrão Limites Alternados - início 256 kbps Figura 51 Variação da banda disponível - Padrão Alternado entre 8 Mbps e 4 Mbps. 96 Figura 52 Variação da banda disponível - Padrão Alternado entre 4 Mbps e 2 Mbps. 96 Figura 53 Variação da banda disponível - Padrão Alternado entre 2 Mbps e 1 Mbps. 97 Figura 54 Variação da banda disponível - Padrão Alternado entre 1 Mbps e 256 kbps Figura 55 Zone plate 1, após codificação H.264 em 1,438 Mbps pelo DASHEncoder. 98 Figura 56 Zone plate 1, após codificação H.264 em 1,845 Mbps pelo DASHEncoder. 99 Figura 57 Zone plate 1, após codificação H.264 em 2,205 Mbps pelo DASHEncoder. 99 Figura 58 Zone plate 2, após codificação H.264 em 1,438 Mbps pelo DASHEncoder.100 Figura 59 Zone plate 2, após codificação H.264 em 1,845 Mbps pelo DASHEncoder.100 Figura 60 Zone plate 2, após codificação H.264 em 2,205 Mbps pelo DASHEncoder.100 Figura 61 Eighth Ave, após codificação H.264 em 1,438 Mbps pelo DASHEncoder. 101 Figura 62 Eighth Ave, após codificação H.264 em 1,845 Mbps pelo DASHEncoder. 101 Figura 63 Eighth Ave, após codificação H.264 em 2,205 Mbps pelo DASHEncoder. 102 Figura 64 Exemplo de artefatos no vídeo Figura 65 Variação da taxa do zone plate 1 para banda ilimitada ix

11 Figura 66 Variação da taxa do zone plate 1 para banda limitada a 8 Mbps Figura 67 Variação da taxa do zone plate 1 para banda limitada a 4 Mbps Figura 68 Variação da taxa do zone plate 1 para banda limitada a 2 Mbps Figura 69 Variação da taxa do zone plate 1 para banda limitada a 1 Mbps Figura 70 Variação da taxa do zone plate 1 para banda limitada a 256 kbps Figura 71 Variação da taxa do zone plate 2 para banda ilimitada Figura 72 Variação da taxa do zone plate 2 para banda limitada a 8 Mbps Figura 73 Variação da taxa do zone plate 2 para banda limitada a 4 Mbps Figura 74 Variação da taxa do zone plate 2 para banda limitada a 2 Mbps Figura 75 Variação da taxa do zone plate 2 para banda limitada a 1 Mbps Figura 76 Variação da taxa do zone plate 2 para banda limitada a 256 kbps Figura 77 Variação da taxa demandada pela 8ave codificado em 1,438 Mbps Figura 78 Variação da taxa demandada pela 8ave codificado em 1,845 Mbps Figura 79 Variação da taxa demandada pela 8ave codificado em 2,205 Mbps Figura 80 Variação da taxa demandada por ZP1, codificado para ABR, em banda ilimitada Figura 81 Variação da taxa demandada por ZP2, codificado para ABR, em banda ilimitada Figura 82 Variação da taxa demandada por 8ave, codificado para ABR, em banda ilimitada Figura 83 Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão decrescente Figura 84 Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão decrescente Figura 85 Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão decrescente Figura 86 Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão crescente Figura 87 Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão crescente Figura 88 Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão crescente Figura 89 Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão de limites alternados com início em 8 Mbps. 125 Figura 90 Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão de limites alternados com início em 8 Mbps. 126 Figura 91 Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão de limites alternados com início em 8 Mbps. 127 x

12 Figura 92 Figura 93 Figura 94 Figura 95 Figura 96 Figura 97 Figura 98 Figura 99 Figura 100 Figura 101 Figura 102 Figura 103 Figura 104 Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão de limites alternados com início em 256 kbps Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão de limites alternados com início em 256 kbps Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão de limites alternados com início em 256 kbps Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 8 Mbps e 4 Mbps Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 8 Mbps e 4 Mbps Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 8 Mbps e 4 Mbps Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 4 Mbps e 2 Mbps Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 4 Mbps e 2 Mbps Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 4 Mbps e 2 Mbps Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 2 Mbps e 1 Mbps Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 2 Mbps e 1 Mbps Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 2 Mbps e 1 Mbps Variação da taxa demandada por ZP1, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 1 Mbps e 256 kbps xi

13 Figura 105 Figura 106 Figura 107 Figura 108 Variação da taxa demandada por ZP2, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 1 Mbps e 256 kbps Variação da taxa demandada por 8ave, codificado para ABR, em flutuação de banda no padrão de limites alternados entre 1 Mbps e 256 kbps Área que representa a quantidade de kbits carregada no reprodutor até o instante de ZeroWindow Quantidade de pedaços de vídeo reproduzidos até o instante de ZeroWindow xii

14 Lista de tabelas Tabela 1 Tempo Mensal de Navegação por pessoa (hh:mm) - Dez/ Tabela 2 Lista dos países com maior quantidade de assinaturas de Internet fixa em Tabela 3 Limites mínimos de velocidade da banda larga ficam mais rigorosos.. 15 Tabela 4 Aplicações Top 10 de consumo da Internet no horário de pico na América do Norte em acessos fixos (Upstream e Downstream) Tabela 5 Capacidade mínima de backhaul em relação aos habitantes por município. 18 Tabela 6 Program Specific Information (PSI) Tabela 7 MPD gerada nos testes do DASH Tabela 8 Requisições HTTP do cliente para o servidor DASH Tabela 9 Classes de endereços IP Tabela 10 Máscara de sub-rede: divisão pela operação AND Tabela 11 Divisão de sub-redes Tabela 12 Quantidade de sub-redes em relação ao empréstimo de bits Tabela 13 Agrupamento em words Tabela 14 Somatória das words Tabela 15 Cabeçalho IP final Tabela 16 Cabeçalho IP no receptor Tabela 17 Cálculo da somatória no receptor Tabela 18 Caso de erro na transmissão Tabela 19 Mensagem requisição do Mini-PC Android Tabela 20 Alguns tipos de métodos de requisições HTTP Tabela 21 Resposta HTTP do reprodutor DASH Tabela 22 Alguns códigos de estados em respostas HTTP Tabela 23 Alguns tipos de métodos RTSP Tabela 24 Exemplo de troca de mensagens RTSP para SETUP Tabela 25 Exemplo de troca de mensagens RTSP para PLAY Tabela 26 Exemplo de troca de mensagens RTSP para PAUSE Tabela 27 Exemplo de troca de mensagens RTSP para TEARDOWN Tabela 28 Resumo da reprodução DASH - Sem erros ( ) ou com erros (X) Tabela 29 Tempo entre solicitação e reprodução para as sequências ZP1 e ZP

15 Tabela 30 Comparação das taxas de reprodução com as taxas de manutenção do streaming em DASH Tabela 31 Trecho do log da reprodução DASH Tabela 32 Resumo da reprodução para as sequências DASH, para ABR, em banda ilimitada Tabela 33 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão decrescente Tabela 34 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão crescente Tabela 35 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão de limites alternados com início em 8 Mbps.125 Tabela 36 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão de limites alternados com início em 256 kbps Tabela 37 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão de limites alternados entre 8 Mbps e 4 Mbps Tabela 38 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão de limites alternados entre 4 Mbps e 2 Mbps Tabela 39 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão de limites alternados entre 2 Mbps e 1 Mbps Tabela 40 Resumo da reprodução para as sequências DASH, para ABR, em flutuação de banda no padrão de limites alternados entre 1 Mbps e 256 kbps Tabela 41 Resultado para quantidade de bits carregados para o reprodutor DASH até ZeroWindow Tabela 42 Resultado para quantidade de bits reproduzidos pelo reprodutor DASH até ZeroWindow Tabela 43 Tamanho do buffer do reprodutor DASH, em KBytes Tabela 44 Tamanho do buffer do reprodutor DASH, em segundos Tabela 45 Relação entre o momento de ZeroWindow (buffer completo) e fim do pico com a transição para a estabilidade xiv

16 Lista de siglas 3GPP AAC ABNT ABR ACK AHS ANATEL APP ASC ASI ATSC AVC BTS CAT CBQ CBR CDN CETIC CNAME CPU CR CSRC CWR DASH DCT DMB DQPSK DTS 3rd Generation Partnership Project Advanced Audio Coding Associação Brasileira de Normas Técnicas Adaptive Bit Rate Acknowledgment Adaptive HTTP Streaming Agência Nacional de Telecomunicações Application-specific Functions American Standard Code for Information Interchange Asynchronous Serial Interface Advanced Television Systems Committee Advanced Video Coding Broadcast Transport Stream Conditional Access Table Class Based Queuing Constant Bit Rate Content Delivery Network Centro de Estudos sobre as Tecnologias da Informação e da Comunicação Canonical Name Central Processing Unit Carriage Return Contributing Source Congestion Window Reduced Dynamic Adaptive Streaming over HTTP Discrete Cosine Transform Digital Multimedia Broadcasting Differential Quadrature Phase Shift Keying Decoding Time Stamp xv

17 DVB-T DVD DWT ECE ECN ES FDCT FIN FM GOP GSMA HAS HD HDTV HE HLS HTML HTTP IBOPE ICC IDCT IEC IETF IFFT IHL IID IIP IP IPD ISO ITU ISDB-T Digital Video Broadcasting - Terrestrial Digital Versatile Disc Discrete Wavelet Transform Explicit Congestion Notification Echo Explicit Congestion Notification Elementary Stream Forward Discrete Wavelet Transform Fim Frequência Modulada Groups of Pictures Global System for Mobile Communications Association HTTP Adaptive Streaming High Definition High Definition Television High Efficiency HTTP Live Streaming HyperText Markup Language Hypertext Transfer Protocol Instituto Brasileiro de Opinião Pública e Estatística Inter-channel Cross-Correlation Inverse Discrete Cosine Transform International Electrotechnical Commission Internet Engineering Task Force Inverse Fast Fourier Transform Internet Header Length Inter-channel Intensity Difference ISDB-T Information Packets Internet Protocol Interchannel Phase Difference International Organization for Standardization International Telecommunication Union Integrated System Digital Broadcasting - Terrestrial xvi

18 JVT LAN LF MIME MPD MPEG MTU MVD NIT NPT NTSC OFDM OSI OTT PAL PAT PC PCR PES PGMU PID PMT PNBL PNS PS PSH PSI PTS QAM QMF QPSK RAM Joint Video Team Local Area Network Line Feed Multipurpose Internet Mail Extensions Media Presentation Description Moving Picture Experts Group Maximum Transmission Unit Motion Vector Diference Network Information Table Normal Play Time National Television System Committee Orthogonal Frequency Division Multiplexing Open Systems Interconnection Over-the-top Phase Alternating Line Program Association Table Personal Computer Program Clock Reference Packetized Elementary Stream Plano Geral de Metas de Universalização do Serviço Telefônico Fixo Comutado Packet Identification Program Map Table Plano Nacional de Banda Larga Perceptual Noise Substitution Parametric Stereo Push Program Specific Information Presentation Time Stamp Quadrature Amplitude Modulation Quadrature Mirror Filter Quadrature phase-shift keying Random Access Memory xvii

19 RF RFC RR RST RTP RTCP RTMP RTSP SBR SD SDES SDI SMPTE SP SPI SR SSRC SYN TCP TS TNS TTL TV UDP UHF URG URL UTP VBR VCR VHF VLC Rádio Frequência Request For Comments Receiver Report Reset Real-time Transport Protocol Real-Time Transport Control Protocol Real Time Messaging Protocol Real-Time Streaming Protocol Spectral Band Replication Standard Definition Source Description Serial Digital Interface Society of Motion Picture and Television Engineers Space Serial Peripheral Interface Sender Report Synchronization Source Synchronize Sequence Numbers Transmission Control Protocol Transport Stream Temporal Noise Shaping Time To Live Televisão User Datagram Protocol Ultra High Frequency Urgente Uniform Resource Locator Unshielded Twisted Pair Variable Bit Rate Video Recorder Very High Frequency Variable Length Coding xviii

20 WAN XML ZP Wide Area Network extensible Markup Language Zone Plate xix

21 Sumário Lista de figuras Lista de tabelas Lista de siglas Sumário viii xiii xv xx 1 INTRODUÇÃO OBJETIVO ORGANIZAÇÃO DA DISSERTAÇÃO TV DIGITAL E SEUS NOVOS MODELOS NOVOS MODELOS DE DISTRIBUIÇÃO DE ÁUDIO E VÍDEO DI- GITAIS DESAFIOS DA BANDA LARGA BRASILEIRA Plano Nacional de banda larga (PNBL) DYNAMIC ADAPTIVE STREAMING OVER HTTP (DASH) AS TRÊS PRINCIPAIS FORMAS DE STREAMING Streaming Download progressivo Streaming adaptativo Início do streaming adaptativo ao surgimento DASH DASH - Abordagem técnica Codificação fonte: MPEG-2 Systems, compressão e empacotador DASH MPEG-2 systems Compressão do áudio: MPEG-4 HE-AAC Compressão do vídeo: H Empacotamento MP4Box

22 3.3.2 Estruturação do conteúdo e funcionamento do DASH CONCEITOS DE REDES IP APLICADOS AO STREAMING MODELOS OSI E TCP/IP Modelo OSI Camada de aplicação Camada de apresentação Camada de sessão Camada de transporte Camada de rede Camada de enlace de dados Camada física Modelo TCP/IP Camada de enlace Camada de Internet Camada de transporte Camada de aplicação CAMADA DE REDE: ENCAPSULAMENTO IP Endereçamento IP Cabeçalho IP Versão Internet header length (IHL) Tipo de serviço Tamanho Total Identificação Flags Offset do segmento Time to live (TTL) Protocolo Checksum do cabeçalho IP de Origem e Destino Opções e Padding Fragmentação IP xxi

23 4.2.4 Exemplo de aplicação IP no DASH CAMADA DE TRANSPORTE: UDP e TCP UDP Porta de origem e destino Tamanho total Checksum TCP Porta de origem e destino Número de sequência Número de confirmação Comprimento do cabeçalho Flags Tamanho da janela Checksum Ponteiro de urgência Opções Processo de abertura de conexão Processo de fechamento de conexão Exemplo de aplicação TCP no DASH CAMADA DE APLICAÇÃO: HTTP, RTP/RTCP e RTSP HTTP Estrutura da requisição Estrutura da resposta Sintaxe das mensagens HTTP RTP e RTCP RTP Exemplo de cabeçalho RTP possível nos testes RTCP RTSP Sintaxe das mensagens RTSP DASH: TESTES PRÁTICOS MATERIAL E METODOLOGIA xxii

24 5.2 RESULTADOS E DISCUSSÃO DO COMPORTAMENTO DA REDE PARA A REPRODUÇÃO DASH Reprodução do DASH, codificado em constant bit rate (CBR), com limitação de banda fixa Reprodução do DASH e a sua relação com as taxas de codificação Reprodução do DASH, codificado em adaptive bit rate (ABR), com limitação de banda variável Sequências em banda ilimitada Sequências em limitação no padrão decrescente Sequências em limitação no padrão crescente Sequências em limitação no padrão de limites alternados com início em 8 Mbps Sequências em limitação no padrão de limites alternados com início em 256 kbps Sequências em limitação no padrão de limites alternados entre 8 Mbps e 4 Mbps Sequências em limitação no padrão de limites alternados entre 4 Mbps e 2 Mbps Sequências em limitação no padrão de limites alternados entre 2 Mbps e 1 Mbps Sequências em limitação no padrão de limites alternados entre 1 Mbps e 256 kbps MEDIÇÃO DO BUFFER DO REPRODUTOR DASH (VLC) Procedimentos para o cálculo do buffer Resultados e discussão sobre o buffer do VLC (reprodutor DASH) CONCLUSÃO 148 Referências 150 xxiii

25 1 INTRODUÇÃO Atualmente se observa um forte crescimento do uso de dispositivos conectados em rede, tais como smartphones, tablets e set-top-boxes. Dados da International Telecommunication Union (2011) evidenciam que de 2006 a 2011 a quantidade de aparelhos celulares saltou de um número próximo de três bilhões, para aproximadamente seis bilhões. O mesmo documento traz a informação de que, no mesmo período, as assinaturas de banda larga móvel aumentaram 45% ao ano. Esse aumento fez com que, em 2011, o acesso à banda larga móvel chegasse, praticamente, ao dobro do número de assinaturas em relação ao mercado de Internet por cabo. Além do aumento na quantidade de aparelhos, o consumo de dados para cada dispositivo também está em forte crescimento. Na projeção da CISCO (2012) sobre o futuro do consumo de dados em aparelhos móveis mediu-se que em 2011 este estava em 0,6 Exabytes por mês e espera-se chegar a 10,8 Exabytes por mês em Desses dados, 48,3% serão consumidos por smartphones, 24,2% por laptops e notebooks e 10% por tablets. Em relação ao tipo de dado consumido, o mesmo white paper revela que o percentual do consumo de dados móveis para assistir vídeos em 2016 será de 70,5% do total. Assim, juntando as informações da International Telecommunication Union (2011) e da CISCO (2012), pode-se fazer uma projeção que em 2016 se estará consumindo algo em torno de 7,6 Exabytes por mês somente na visualização de vídeos em dispositivos móveis. Percebe-se, portanto, a tendência de fortalecimento de outros tipos de mídia para visualização de conteúdos multimídia, descentralizando o papel da televisão tradicional, pulverizando o conteúdo por meio de dispositivos móveis, convergentes e interconectados. Para possibilitar essa mudança midiática têm sido desenvolvidas diversas tecnologias para o streaming. Dentre os padrões criados, os mais conhecidos são o HTTP Dynamic Streaming da Adobe, o HTTP Live Streaming (HLS) da Apple e o Smooth Streaming Silverlight da Microsoft, todos com tecnologias proprietárias. Para atender a uma necessidade de convergência na utilização do streaming, foi desen- 1

26 volvido o Dynamic Adaptive Streaming over HTTP (DASH). Com a utilização do DASH ocorre uma interoperabilidade de sistemas, possibilitando a entrega, em plataformas diferentes, de um vídeo com streaming a uma taxa que se adapta com a taxa de download e processamento do dispositivo de visualização. Inclusive, por ser uma tecnologia nova, esta deve ser desenvolvida através da pesquisa, de forma a identificar seus nichos de possibilidades de implementação, e de promover constantes melhorias no sistema, que irão amadurecê-lo. 1.1 OBJETIVO É justamente no contexto dessas novas possibilidades que foi proposta a pesquisa ora relatada, que se volta ao estudo dessa nova tecnologia e à compreensão de suas características, com o objetivo de inserir as emissoras televisivas nessa nova realidade de consumo. A partir do entendimento da estrutura básica de streaming foca-se no estudo do DASH como uma possibilidade de complemento da distribuição dos conteúdos televisivos. Para tanto, busca-se verificar quais são os processos necessários para preparar o conteúdo que vai ao ar, via ISDB-T B, para que ele seja transmitido via streaming. Também é estudado, com os testes realizados, o comportamento do DASH, em constant bit rate (CBR) e adaptive bit rate (ABR), para diversas condições de disponibilidade de banda, que podem ser fixas ou flutuantes. 1.2 ORGANIZAÇÃO DA DISSERTAÇÃO Este trabalho apresenta no capítulo 2 um panorama histórico e os desafios no consumo de conteúdos multimídia, que parte da TV para novos modelos, com o advento das plataformas e sistemas para acesso a esse conteúdo via Internet. O capítulo 3 apresenta conceitos sobre o streaming e como o DASH se estrutura e funciona. No capítulo 4 são apresentados os principais conceitos de redes IP, com a teoria focada para a aplicação do streaming de áudio e vídeo. O capítulo 5 aborda os testes práticos realizados com o DASH, para diferentes configurações de taxa e limitações de banda. Nele é apresentada a metodologia utilizada e os resultados, que caracterizam o comportamento da demanda de banda para tecnologia DASH em diferentes situações. Por fim, o capítulo 6 apresenta as conclusões da dissertação e sugestões para trabalhos futuros. 2

27 2 TV DIGITAL E SEUS NOVOS MODELOS Atualmente o mundo presencia uma consolidação dos modelos de equipamentos digitais, em substituição aos analógicos. Tal mudança se faz presente pois a implementação digital tem assumido custos de fabricação cada vez menores e com qualidade e confiabilidade cada vez maiores, se comparadas às soluções analógicas (NVISION, 1996). Além das melhorias já relacionadas, a digitalização do sistema televisivo trouxe uma nova gama de ferramentas que vão desde o controle da processo da captação e produção, até a transmissão do sinal, com a flexibilização de configurações como formatos de áudio e vídeo, codificação e modulação (NVISION, 1999). Antes das transmissões digitais terrestres, desde meados da década de 90, já era possível obter uma programação digital televisiva por um sinal de satélite (ASAMI, 2005). Comercialmente, o início das transmissões digitais terrestres ocorrem em 1998, com o Advanced Television Systems Committee (ATSC), nos Estados Unidos e com o Digital Video Broadcasting - Terrestrial (DVB-T), na Europa (AKAMINE, 2004). Depois, em 2003, o Japão inicia a operação comercial do Integrated System Digital Broadcasting - Terrestrial (ISDB-T), mesmo ano no qual o Brasil criou um convênio para decisão do sistema de TV digital a ser adotado (YAMADA et al., 2004). É abordada nesta pesquisa a versão brasileira do padrão japonês, inaugurada no início de dezembro de 2007, em São Paulo (FÓRUM SBTVD, 2012). As principais diferenças entre o padrão japonês e o brasileiro estão na codificação da fonte, middleware e banda de operação. No sistema japonês é utilizado o H.264 para o codificação de vídeo one-seg 1, o padrão do Moving Picture Experts Group (MPEG), chamado MPEG-2, para a codificação do vídeo para os outros serviços e MPEG-2 Advanced Audio Coding (AAC) para a compressão do áudio (DIBEG, 2007). De acordo com o whitepaper do ministro japonês das telecomunicações, Asami (2005), a faixa espectral 1 Transmissão 1seg é utilizada para dispositivos móveis, caracterizada por utilizar um único segmento da modulação BST-OFDM (BEDICKS JUNIOR, 2008) 3

28 destinada para a radiodifusão 2 da televisão digital japonesa é a Ultra High Frequency (UHF). Vale ressaltar que a canalização do espectro japonês é diferente da estipulada no brasileiro (BEDICKS JUNIOR, 2008). A versão brasileira do ISDB-T se difere da japonesa pois o codec utilizado é o H.264 para vídeo e o MPEG-4 HE AAC para o áudio. Para o middleware desenvolveu-se uma plataforma brasileira, conhecida como Ginga, que permite a interatividade do telespectador com conteúdos fornecidos pela emissora. Outra diferença é que o ISDB-T B pode trabalhar tanto na faixa dos canais de 7 a 13, em Very High Frequency (VHF), como utilizar os canais 14 a 69, em UHF (AKAMINE et al., 2009). Para uma compreensão global do ISDB-T B, a ABNT (2007) apresenta um fluxo básico do sistema de transmissão, separando-o em codificador, multiplexador, modulador e amplificador, conforme a figura 1. O tipo de entrada neste sistema será o áudio, vídeo ou dados em um fluxo Transport Stream (TS), em acordo com o MPEG-2 system. Estes serão remultiplexados para criar um único TS que irá para o modulador, que modulará o sinal, preparando-o para ser transmitido, a partir de uma estrutura Orthogonal Frequency Division Multiplexing (OFDM) com 13 segmentos sucessivos, cada um com 1/14 da largura do canal de televisão (que podem variar entre 5,572MHz, 5,573MHz ou 5,575MHz, de acordo com o modo utilizado). Depois desse processo, o sinal de Rádio Frequência (RF) será amplificado para ser irradiado pela antena em determinada área de cobertura (ABNT 15601, 2007). Figura 1: Fluxo do sistema ISDB-T B. Fonte: ABNT (2007, p. 4). Além dos modelos de radiodifusão, existe um outro modelo de consumo de conteúdo de áudio e vídeo que vem angariando muitos espectadores: o streaming 3 de vídeo pela 2 Anatel (2012) define radiodifusão como serviço de radiodifusão a TV analógica e digital, além do rádio em frequência modulada (operando na faixa de FM) ou amplitude modulada (operando nas na faixa de ondas médias, curtas e tropicais) 3 Austerberry (2005a) define o streaming, no que se diz respeito ao audiovisual, como consumir um 4

29 Internet. A CISCO (2012) projeta que em 2016 dois terços do tráfego de dados mundial será por conta do vídeo, indicando esse expressivo aumento. Austerberry (2005b) traz o fluxo desse tipo de sistema de transmissão multimídia por uma rede Internet Protocol (IP), dividindo-o em quatro macro-blocos. O primeiro é a captura do som e da imagem que serão codificados, resultando em arquivos comprimidos. O segundo bloco é do servidor que armazenará esses arquivos e controlará o streaming. Já a terceira etapa será a distribuição do conteúdo multimídia a partir do uso de uma rede de internet, que leva à última etapa do processo: a visualização do conteúdo em um tocador de mídia. Esse reprodutor, que pode ser um software adicionado como plug-in em um navegador de internet, receberá o stream e o descomprimirá, possibilitando que se veja e ouça o conteúdo transmitido (AUSTERBERRY, 2005b). Pode-se observar o referido sistema na figura 2, apresentada a seguir. Figura 2: Os quatro estágios do streaming. Fonte: Austerberry (2005b, p. 139). Percebe-se que ambos os diagramas são bem similares, pois obedecem os princípios descritos por Shannon (1948), que definiu que um sistema de comunicação consiste em essencialmente cinco partes, conforme a figura 3. A primeira delas é a fonte de informação, conteúdo na medida que ele chega diretamente de algum emissor. 5

30 que produz as mensagens que serão enviadas ao receptor. A segunda é o transmissor, que tem como característica modificar a mensagem para possibilitar a sua transmissão no canal. Esse se configura na terceira parte do sistema, que é o meio pelo qual a mensagem se propagará entre o transmissor e o receptor. É importante ressaltar que o meio pode ser ruidoso, introduzindo erros na mensagem original. O próximo bloco é o receptor, que realiza exatamente o processo inverso do transmissor, buscando reconstituir a mensagem original a partir de um processo de decodificação. Por fim, tem-se o destinatário, para quem a mensagem foi designada (SHANNON, 1948). Figura 3: Sistema de Comunicação de Shannon. Fonte: Shannon (1948, p. 2). 2.1 NOVOS MODELOS DE DISTRIBUIÇÃO DE ÁUDIO E VÍDEO DIGITAIS A Forrester Research realizou uma pesquisa publicada no portal AdAge em março de 2012, que evidencia uma nova realidade no uso das horas livres dos brasileiros. Para tanto, foram entrevistados 2006 brasileiros maiores que 16 anos, e estes afirmaram passar, em uma média semanal, 6,2 horas de seu tempo livre assistindo televisão, enquanto no mesmo período os entrevistados alegaram tomar 23,8 horas semanais na Internet. Dessas pessoas, 86% reportam assistir vídeos na web (DELO, 2012). Estes dados evidenciam um novo paradigma de consumo de conteúdos audiovisuais, pois a maioria das pessoas entrevistadas realizam tal consumo a partir do uso da internet. Assim, a televisão deixa de ser o único meio de se assistir um vídeo, que agora compete com outras mídias interconectadas, 6

31 como o computador, celular e tablets. Dessa forma, as referidas mudanças conduzem ao desenvolvimento de novas tecnologias para atender a uma nova demanda. Uma dessas tecnologias, que surgiu na década de 1990, trata-se de umas das principais técnicas de visualização de vídeos na Internet: o streaming de mídia. Este se dá com o lançamento do RealPlayer da RealNetworks, que possibilitava visualizar streaming de conteúdos multimídia em seu aplicativo (OZER, 2011a). Porém o Windows Media foi o formato que, por volta de 2005, conseguiu a maioria do mercado de distribuição de vídeos streaming, já que a RealNetworks passava por períodos de dificuldades financeiras (OZER, 2011a). Também em 2005, a Macromedia Flash adicionou a tecnologia de codificação On2 Technologies VP6 aos seus produtos, o que o tornou competitivo em relação ao Windows Media, tanto que Ozer (2011a) afirma que em 2009 a maioria dos sites estava estruturado em Flash. A fim de continuar seu desenvolvimento no mercado de visualização de streaming a Microsoft lança em 2007 o Silverlight, sua nova plataforma, muito similar ao Flash. Em 2010 existe um novo cenário, com a decisão da Apple de não lançar o ipad compatível com o Flash e sim com o HTML5, uma atualização do código HyperText Markup Language (HTML). Essa nova versão da linguagem de marcação utiliza uma video tag, possibilitando o carregamento do vídeo pelo navegador (browser), a partir da utilização de um comando do código fonte HTML, não necessitando de plug-ins de aplicativos proprietários para visualizar o vídeo (OZER, 2011a). Juntamente a este cenário, o mundo já enfrentava um crescente consumo de banda nos dispositivos móveis em meio a uma diversidade de plataformas para se assistir vídeos, sendo muitas delas não compatíveis entre si e proprietárias. Tal situação é comprovada pela CISCO (2012), que relata que só no período entre 2011 e 2016 é previsto um aumento de 78% no tráfego de dados em dispositivos móveis. Como agravante para se assistir vídeos em redes móveis ainda se enfrenta uma variação na banda disponível para downloads e uploads, devido às sobrecargas em determinados horários e oscilação da intensidade do sinal. Assim, em 2009, o 3rd Generation Partnership Project (3GPP) decide realizar um padrão para distribuição de mídia em redes com taxas variáveis, com a intenção de suprir essas futuras demandas de consumo multimídia. Além dos diferentes formatos de distribuição streaming, outro motivo para se desenvolver um novo modelo se dá no fato de que 7

32 o padrão de pacotes da 3GPP, utilizado para o streaming multimídia em redes móveis, era o Real-Time Streaming Protocol (RTSP). Tal protocolo é normalmente utilizado para controle do vídeo, na camada de aplicação do modelo OSI, e requer uma infraestrutura exclusiva, além de ter problemas ao passar por firewalls. Já o novo padrão seria baseado no Hypertext Transfer Protocol (HTTP), totalmente convergente com as redes de Internet, além de uniformizar o modo de se distribuir os conteúdos tanto para a Internet, como para os dispositivos móveis (LOHMAR et al., 2011). O nome desse novo modelo ficou conhecido como Dynamic Adaptive Streaming over HTTP (DASH). Posteriormente, o MPEG utilizou como guia o documento 3GP-DASH para realizar sua contribuição no desenvolvimento do sistema, elaborando o padrão MPEG-DASH (LOHMAR et al., 2011). 2.2 DESAFIOS DA BANDA LARGA BRASILEIRA Até aqui foram apresentadas tecnologias que possibilitam a recepção de conteúdos de áudio e vídeo pela Internet, com destaque para o streaming utilizando a nova solução, chamada DASH. Porém para que esta nova forma de consumo de conteúdo audiovisual se torne uma realidade é preciso que haja uma infraestrutura que suporte essa demanda, que aumenta o tráfego pelas redes de Internet. É importante compreender que cada usuário que entra na rede irá aumentar a partilha da banda máxima disponível. Isso acontece pois uma rede de tráfego de dados tem como característica intercalar vários pacotes de dados de usuários diferentes transmitindo-os em um único canal, conforme explica Torres (2001). Na figura 4 é exemplificado esse tipo de transmissão de pacotes de dados, no caso dos computadores A e C para o terminal B. Por esse motivo o autor afirma que a velocidade de transmissão em uma rede de dados é altamente dependente do número de transmissões simultâneas e da demanda de cada usuário. Assim, para que se possa aumentar a capacidade da rede, possibilitando o aumento no número de usuários e da banda disponível para cada um, é preciso investir em uma grande infraestrutura, que envolve novas tecnologias de equipamentos, conexões e protocolos. O Brasil, assim como todo o mundo, enfrenta uma forte demanda para o crescimento da banda disponível da Internet, principalmente quando o fluxo de informação envolve dispositivos móveis. Ricardo Tavares, o vice-presidente de políticas públicas da Global 8

33 Figura 4: Transmissão simultânea de dois arquivos. Fonte: Torres (2001, p. 37). System for Mobile Communications Association (GSMA), organização que representa as operadoras de telefonia móvel, afirmou para revista Info Exame, da Editora Abril, que apesar do aumento da quantidade de celulares ele não vê a possibilidade de acontecer um problema de apagão das ligações de telefones móveis, mas afirma que há um risco desse colapso acontecer na disponibilidade de banda larga utilizada por esses aparelhos. Para Tavares, esse problema tem como causador a falta de investimentos em backhaul, que são as redes de fibra óptica responsáveis por carregar as informações da rede de telefonia móvel (EXAME INFO, 2009). De fato, o crescimento acelerado na quantidade de dados trafegados via web, com o uso de dispositivos móveis conectados, projeta um crescimento exponencial da demanda de banda. A International Telecommunication Union (2013) traz dados que evidenciam o problema do acesso à Internet em banda larga fixa, mostrando a grande disparidade desse tipo de acesso, entre países desenvolvidos e em países em desenvolvimento, conforme observa-se na figura 5. Vale ressaltar que a International Telecommunication Union (2013) considera como banda larga acessos à Internet com velocidades superiores a 256 kbps. Trazendo a realidade brasileira, o IBOPE Nielsen Online (2013) apresenta dados, expostos na tabela 1, que apontam que o Brasil está em primeiro lugar na lista mundial do tempo mensal de navegação na Internet por pessoa, superando países como França e 9

34 Porcentual dos habitantes Desenvolvidos Mundo Em Desenvolvimento * 2013* Ano 27,2 Figura 5: Assinaturas de Banda Larga Fixa (%) em relação ao desenvolvimento do país, Fonte: International Telecommunication Union (2013, p. 4). *Nota: Dados Estimados. 9,8 6,1 Alemanha. Desta forma fica evidente que existe demanda brasileira por crescimento do acesso à Internet. Tabela 1: Tempo Mensal de Navegação por pessoa (hh:mm) - Dez/2012 Posição País Navegação em Páginas 1 o Brasil 43:57 2 o França 39:23 3 o Alemanha 37:23 Fonte: Adaptado de IBOPE Nielsen Online (2013). Tais tempos de navegação podem ser interpretados como espera no download e upload, o que infere que seria possível uma redução no tempo de uso caso a velocidade de acesso fosse maior. Porém, a figura 6 evidencia que, independente da velocidade de acesso à Internet, o Brasil ainda está em primeiro lugar nesse requisito, entre os países comparados. Não é somente no tempo de navegação que o Brasil está na frente de países considerados desenvolvidos, mas também na quantidade de assinaturas de Internet fixa. A figura 7 mostra que em 2007 o Brasil superou a Espanha, em 2008 o Canadá, no ano de 2010 a Itália e em 2012 estava muito próximo à Coréia do Sul. Com esse crescimento o Brasil, em 2012, figura como o nono país da lista mundial desse tipo de conexão, conforme é mostrado na tabela 2 (INTERNATIONAL TELECOMMUNICATION UNION, 2013). 10

35 Brasil Itália Espanha França Reino Unido Austrália Alemanha EUA Suíça 10:00:53 30:59:15 31:54:42 31:57:18 30:53:42 24:49:13 24:20:36 22:15:38 21:57:51 25:57:01 28:05:41 24:52:04 22:28:58 26:48:23 28:43:32 25:58:04 28:30:36 22:40:30 24:17:33 22:07:13 23:08:07 22:40:30 24:17:33 22:07:13 20:49:52 28:24:53 28:29:23 26:52:39 27:25:20 25:48:11 27:22:21 26:23:37 25:33:04 21:19:58 20:14:46 17:38:18 0:00:00 4:48:00 9:36:00 14:24:00 19:12:00 24:00:00 28:48:00 33:36:00 Acima de 8Mb 2Mb - 8Mb 512kb - 2Mb Abaixo de 512kb Figura 6: Tempo de navegação de Internet por Velocidade de Conexão. Fonte: Adaptado de Nielsen (2011, p. 2). Tabela 2: Lista dos países com maior quantidade de assinaturas de Internet fixa em Posição País Assinaturas de Internet Banda Larga Fixa 1 o China o Estados Unidos o Japão o Alemanha o França o Reino Unido o Rússia o Korea do Sul o Brasil o Índia Fonte: Adaptado de International Telecommunication Union (2013). 11

36 Milhões de Acessos Fixos Rússia Coréia do Sul Brasil Itália Canadá Espanha Supera Espanha Próximo à Coréia Supera Canadá Supera Itália Ano Figura 7: Comparativo da quantidade de assinaturas de Internet em banda larga fixa entre 2003 e Fonte: Adaptado de International Telecommunication Union (2013). O crescimento dos dados relacionados ao tempo de navegação e de número de usuários demonstram que a demanda por Internet está sendo atendida de certa forma, pois ao contrário não haveria crescimento. Porém, é importante refletir quanto a qualidade da Internet entregue ao consumidor, principalmente no que se diz respeito à velocidade de acesso. Também em relação à taxa de transferência, a figura 8 mostra a distribuição da audiência de Internet por velocidade de conexão em diferentes países. Os dados apresentados revelam que os países que nas comparações anteriores estiveram atrás do Brasil fornecem uma velocidade média do serviço de banda larga bem superior ao brasileiro. O percentual de acessos com velocidades maiores que 2 Mbps dos oito países que são comparados ao Brasil estão entre os valores de 88% na Suíça e de 64% na Austrália e Itália, enquanto no Brasil esta realidade está em somente 21% da audiência conectada. O cenário brasileiro tem quase metade de acessos realizados a uma taxa de 512 kbps a 2 Mbps, sendo que 79% da população internauta navega com velocidades abaixo de 2 Mbps. O impacto da baixa média de velocidade de Internet brasileira se dá em serviços como 12

37 Figura 8: Audiência de Internet por Velocidade de Conexão. Fonte: Adaptado de Nielsen (2011, p. 1). armazenamento e utilização de dados em nuvem 4 e visualização de vídeos na web, já que a velocidade de conexão é um fator muito importante para que se consiga utilizar serviços. Atualmente o serviço de streaming de vídeo é altamente impactado pelo perfil da velocidade de Internet brasileira. É preciso considerar também que as maiores operadoras de banda larga residenciais trabalham em um modelo de negócio no qual a banda fornecida ao cliente é compartilhada entre vários usuários, não sendo um link dedicado, conforme contrato da Vivo (2012) e da NET (2011). Desta forma, ao analisar o contrato dessas empresas está claramente explicitado que as velocidades contratadas são nominais máximas e sujeitas a variações decorrentes, entre outros motivos, da quantidade de pessoas conectadas ao mesmo tempo ao provedor (VIVO, 2012). Inclusive, o contrato da NET (2011), além de explicitar que a velocidade contratada é a máxima, existe uma cláusula que garante ao cliente somente 10% da velocidade nominal contratada. Juntando essas condições com os dados apresentados na figura 8, pode-se chegar a estabelecer um cenário no qual 79% dos clientes brasileiros terão como garantia velocidades abaixo de 200 kbps (10% de 2 Mbps). Para se ter uma idéia de quão baixa é essa taxa 4 No documento do National Institute of Standards and Technology Badger et al. (2011, p. 2-1) definem Cloud Computing como um modelo que possibilita um acesso, por conveniência e demanda, a uma rede que compartilha um banco de recursos computacionais (por exemplo, armazenamento, aplicativos e serviços) que podem ser rapidamente fornecidos e liberados com mínimo gerenciamento e interação com o provedor. 13

38 basta verificar algumas recomendações mínimas de perfis de streaming. Por exemplo, para se utilizar o HTTP Live Streaming (HLS) da Apple são estabelecidos, pela empresa, alguns perfis que relacionam resolução e qualidade à taxas de transmissão. O perfil com a menor taxa de bits com som e imagem é com o vídeo em 480x320, transmitido por uma rede de celular com a taxa total de 150 kbps (APPLE INC., 2011). No caso da Adobe, utilizando o HTTP Dynamic Streaming, a menor taxa recomendada é para uma imagem 512x288, que se configura em 400 kbps (LEVKOV, 2010). Assim, em ambos os casos a maioria dos brasileiros, no cenário exemplificado neste parágrafo, estariam no limiar das recomendações, existindo a possibilidade de talvez nem conseguirem visualizar o vídeo no perfil mais simples possível. Portanto, se forem comparados os dados de tempo de acesso, aspecto no qual o Brasil lidera o ranking, com a posição do país em velocidade de Internet, fica claro que novos investimentos no setor são extremamente necessários e urgentes. Sobre esses tipos de aplicações em nuvem, Rafique et al. (2011) defendem que para que exista um desenvolvimento na área de comunicação é necessário que existam redes confiáveis de alta velocidade de transmissão. Somente com um investimento nas redes de transmissão, visando melhorias em sua capacidade e confiabilidade, será economicamente viável o uso de serviços em nuvem (RAFIQUE et al., 2011). A demanda por tais investimentos é tão grande que ela deixou de ser interesse unicamente das empresas fornecedoras de serviços em nuvem, mas também do Governo Federal brasileiro, que criou, em 2010, um plano para acesso a banda larga no Brasil, conhecido como PNBL. No documento base do programa é dito que um fator limitante à ampliação do acesso à internet em banda larga por meio de diferentes plataformas tecnológicas é a carência de infraestrutura (BRASIL, 2010). Vale ressaltar que a ANATEL tem estabelecido novos limites para melhoria da velocidade entregue ao usuário, com um plano de metas entre 2012 e 2014, conforme tabela 3. A partir de novembro de 2013, definiu-se que o valor médio mensal da velocidade deve ser pelo menos 70% da contratada e que a velocidade instantânea mínima deve ser 30% da contratada (ANATEL, 2013). Dados do relatório semestral da Sandvine (2013) trazem que a realidade da alta demanda de tráfego da rede para consumo de conteúdos multimídia via streaming. No fechamento do ano de 2013 confirma-se essa realidade pois, conforme confronta-se na tabela 4, as duas aplicações que mais consomem banda de Internet para download na 14

39 Tabela 3: Limites mínimos de velocidade da banda larga ficam mais rigorosos Data Taxa Média Taxa Instantânea Mudança (download e upload) (download e upload) Novembro de % da máxima contratada 20% da máxima contratada Novembro de % da máxima contratada 30% da máxima contratada Novembro de % da máxima contratada 40% da máxima contratada Fonte: Adaptado de ANATEL (2013). América do Norte, durante o período de pico, Netflix e Youtube, são de streaming de áudio e vídeo. Se somados seus porcentuais chega-se a 50,31% do tráfego de downloads da Internet no período de maior acesso. Apesar do consumo de vídeo demandar uma taxa maior de download do que upload a tabela traz que essas duas empresas também ocupam de relevância em Upstream, com o Netflix em 4 o e YouTube em 5 o lugar. Tabela 4: Aplicações Top 10 de consumo da Internet no horário de pico na América do Norte em acessos fixos (Upstream e Downstream). Upstream Downstream Posição Aplicação Porcentual Aplicação Porcentual 1 BitTorrent 36,35% Netflix 31,62% 2 HTTP 6,03% YouTube 18,69% 3 SSL 5,87% HTTP 9,74% 4 Netflix 4,44% BitTorrent 4,05% 5 YouTube 3,63% itunes 3,27% 6 Skype 2,76% MPEG 2,60% 7 QVoD 2,55% SSL 2,05% 8 Facebook 1,54% Amazon Video 1,61% 9 FaceTime 1,44% Facebook 1,31% 10 Dropbox 1,39% Hulu 1,29% Fonte: Adaptado de Sandvine (2013). O cenário para a América Latina também não diverge dos resultados obtidos para a América do Norte, conforme observa-se na figura 9. Destaca-se na figura 9 o porcentual para a categoria de Entretenimento em Tempo Real, que ocupa a maior porcentagem em todas as comparações, com valores próximos à metade dos downloads e mais do que o dobro consumido na navegação web. O relatório da Sandvine (2013) define a categoria de Entretenimento em Tempo Real como streaming de áudio e vídeo. Portanto, conclui-se que também na América Latina o porcentual de demanda para esse tipo de consumo de conteúdo é bem elevado. 15

40 100% 90% 80% 70% 10,45% 8,19% 8,65% 3,04% 3,19% 10,99% 8,13% 8,59% 9,28% 14,41% Outros Tunneling 60% 50% 41,46% 22,23% 20,39% Redes Sociais 40% ComparGlhamento de Arquivos 30% 20% 10% 10,64% 21,81% 49,13% 44,78% Navegação Web Entretenimento em Tempo Real 0% Upstream Downstream Valor Agregado Figura 9: Composição do tráfego de Internet no período de pico para a América Latina e em acessos fixos. Fonte: Adaptado de Sandvine (2013, p. 23). O relatório da Sandvine (2013) também traz dados comparativos relacionado à um novo produto do Netflix, que já é um alto consumidor de tráfego, e com sua novidade tenderá a aumentar ainda mais seu consumo. A empresa realizou o lançamento do Streaming em Super HD 1080p. Os dados apresentados mostram que a taxa máxima para visualização de conteúdos HD 1080p pelo Netflix chega a 3850 kbps. Mas com seu novo produto ela chegará a 5800 kbps, ou seja, uma diferença de 50,6%. Dessa forma, pode-se inferir que futuramente os números da demanda do Netflix tendem a aumentar ainda mais. Em suma, os dados apresentados mostram que o streaming de áudio e vídeo traz uma elevada demanda por banda de Internet, tanto para o mercado da América do Norte quanto a Latina. A análise do relatório também mostra que essa é uma realidade mundial, já que para os outros continentes apresenta-se um cenário muito similar. 16

41 2.2.1 Plano Nacional de banda larga (PNBL) Em 15 de setembro de 2009 o então presidente da República, Luiz Inácio Lula da Silva, convocou uma reunião com os Ministérios envolvidos com a inclusão digital no intuito de que todos eles elaborassem um programa em comum, que visasse a ampliação do número de usuários com acesso à Internet em banda larga em todo o Brasil. Especialistas em infraestrutura, regulação e serviços foram convidados para elaborar o programa, apresentando a proposta final ao presidente da República em reunião no dia 8 de abril de Depois, em 13 de maio de 2010 foi publicado no Diário Oficial da União o Decreto n o 7175, instituindo o Programa Nacional de Banda Larga (BRASIL, 2010). A referida política pública é de importante atenção ao desenvolvimento do uso de serviços de streaming multimídia no Brasil, já que o próprio conceito de banda larga adotado no programa envolve o áudio e vídeo, conforme trecho extraído do documento base do PNBL: O acesso em banda larga é caracterizado pela disponibilização de infraestrutura de telecomunicações que possibilite tráfego de informações contínua, ininterrupto e com capacidade suficiente para aplicações de dados, voz e vídeo mais comuns ou socialmente relevantes (BRASIL, 2010, p. 18). Tal programa tem como fator motivacional que o acesso a banda larga está intimamente ligado ao desenvolvimento econômico e social de um país. Isso porque quanto maior o ingresso de usuários com internet de alta velocidade maior será o mercado potencial para serviços pela rede, que demandará mais investimento no setor, tornando-se um ciclo virtuoso de desenvolvimento tecnológico e econômico (BRASIL, 2010). Quanto ao social, o aumento do acesso inclui o cidadão, pois ele poderá utilizar serviços públicos digitais, como governo eletrônico, educação à distância e bancos, além do acesso à cultura, informação e entretenimento (como vídeos, música e redes sociais) (BRASIL, 2010). Para aumento do acesso a banda larga o PNBL propõe o foco, inicialmente, no desenvolvimento de uma infraestrutura de rede com capacidade de suportar o aumento da banda requerida pelo desenvolvimento do programa. Essa estrutura também deverá ser o mais abrangente possível de tal forma a disponibilizar o serviço para toda a população, seja ela urbana ou rural, central ou periférica, rica ou pobre. O segundo foco inicial está 17

42 em políticas produtivas e tecnológicas, visando melhorar o sistema regulatório do setor (BRASIL, 2010). Os pilares do PNBL são três: redução de preço, aumento de cobertura e aumento da velocidade. Assim, o primeiro irá facilitar as condições para se ter o serviço, o segundo procura não restringir o acesso ao local de moradia do usuário e o terceiro visa a igualdade do país com a realidade do resto do mundo (BRASIL, 2010). Para tal, as ações do PNBL abordam algumas áreas específicas. Uma delas é a regulação e normas de infraestrutura, para aumentar a competitividade no setor e a oferta do serviço. Outras ações envolvem incentivos fiscais, para reduzir os custos repassados aos cidadãos. Também existem medidas que incentivam uma política produtiva e tecnológica, investindo na indústria nacional. Outros esforços estarão na criação de uma rede nacional de fibras ópticas, sob domínio da União, operada pela Telebrás, que pretende atingir municípios até 2014 (BRASIL, 2010). Quanto à capacidade de backhaul, o Decreto n. o 6424/2008 estabelece uma relação entre número de habitantes em cada cidade e a velocidade mínima de conexão nelas, conforme a tabela 5 (BRASIL, 2010). O decreto está dentro do Plano Geral de Metas de Universalização do Serviço Telefônico Fixo Comutado (PGMU), que foi revisado em junho de 2011, mantendo as metas do decreto de 2008 para o quinquênio (Computer World, 2011). Tabela 5: Capacidade mínima de backhaul em relação aos habitantes por município. Quantidade de habitantes Capacidade mínima de backhaul até 20 mil 8 Mbps entre 20 e 40 mil 16 Mbps entre 40 e 60 mil 32 Mbps acima de 60 mil 64 Mbps Fonte: Adaptado de Brasil (2010). Dessa forma, caso o PNBL consiga ter suas metas atingidas, a situação da Internet brasileira terá grandes avanços, melhorando o mercado de serviços que a utiliza como meio de atendimento de seus clientes. Trazendo este fato para o escopo deste trabalho, existe um modelo de distribuição de conteúdos multimídia, chamado over-the-top (OTT), que se beneficiará com as medidas do PNBL. Os serviços de vídeo OTT têm como característica o fornecimento do conteúdo audiovisual utilizando uma rede não gerenciada pelas empresas 18

43 fornecedoras deste conteúdo (ROSENBLATT, 2011). Desta forma elas só disponibilizam seus serviços, ficando a cargo do seu cliente a contratação de uma outra empresa para fornecer o meio de transmissão deste conteúdo até o usuário. Este modelo se diferencia em relação aos emissores broadcast, que utilizam como meio de entrega do conteúdo uma rede gerenciada por eles mesmos, não terceirizando-a (ROSENBLATT, 2011). 19

44 3 DYNAMIC ADAPTIVE STREAMING OVER HTTP (DASH) Conforme apresentado no capítulo 2, atualmente existe uma forte demanda no consumo de áudio e vídeo pela Internet, que é realizado por diversas tecnologias de streaming. Justamente sobre essas técnicas que este capítulo aborda, com o foco na sua nova versão, o DASH. Primeiramente são abordados os três principais procedimentos para distribuição e visualização multimídia na Internet. Depois é apresentado o panorama para surgimento do DASH e, posteriormente, como se estrutura e funciona essa nova tecnologia. 3.1 AS TRÊS PRINCIPAIS FORMAS DE STREAMING Nesta seção são explicados alguns conceitos principais das formas de distribuição e visualização multimídia na internet: streaming, download progressivo e o streaming adaptativo. Após essa exposição será possível explicar o DASH e seu caráter híbrido Streaming Austerberry (2005a) define que para existir um streaming de vídeo o receptor deve visualizar o conteúdo em tempo real imediatamente no momento de chegada deste conteúdo, em um processo contínuo. Tal característica de recepção tem uma forma similar ao início da televisão, há por volta de 70 anos, em que o sinal das câmeras e microfones dos estúdios eram enviados continuamente aos televisores, que exibiam a programação na medida que esta era capturada (AUSTERBERRY, 2005a). Em uma abordagem técnica, Ozer (2011a) defende que um stream deve ser entregue via um servidor streaming, que difere de um servidor web, que é mais utilizado para websites, textos em HyperText Markup Language (HTML), imagens e arquivos. Um aspecto a ser considerado em relação ao streaming é a disponibilidade de conteúdos a uma taxa de bit fixa. Para que o cliente possa assistir um vídeo com uma determinada 20

45 taxa de bits ele terá que ter um link com uma taxa igual ou superior à do conteúdo para possibilitar uma fluência na visualização. Caso contrário, o consumidor teria que esperar um trecho do vídeo ser armazenado na máquina (processo conhecido como buffer) para depois continuar a reprodução, gerando uma interrupção na visualização. O que pode acontecer no streaming com taxas não compatíveis é que o vídeo irá começar a ser reproduzido e depois irá parar, sendo essa uma das principais reclamações relacionadas a esta forma de distribuição de conteúdo (AUSTERBERRY, 2005c). Esta é uma situação análoga a uma empresa que deve ter uma taxa de entrega de um produto igual à sua produção para que a velocidade de fabricação seja repassada ao cliente, caso contrário o produto ficará estocado na espera de ser entregue. Um outro fator a se considerar em relação à taxa de bit é que a conexão entre o servidor e o cliente normalmente está exposta a diferentes interferências (eletromagnéticas, atenuações atmosféricas, espalhamento óptico etc.) e a congestionamentos da rede em horários de pico. Tais intervenções ocasionarão uma variação da taxa de bits disponível durante o tempo de conexão. Desta forma, as interrupções na visualização do vídeo acontecerão todas as vezes que a taxa do link variar para um valor menor que a taxa do vídeo Download progressivo Em relação ao método download progressivo, Ozer (2011a) caracteriza-o pela entrega do conteúdo utilizando um servidor web de Hypertext Transfer Protocol (HTTP). O uso desta estrutura traz um vantagem em relação a utilização de servidores exclusivos streaming, pois os servidores web estão implementados em todo mundo, já que eles são, em sua maioria, os responsáveis pela navegação em sites na web. No download progressivo, o cliente faz um download do áudio e vídeo e estes são armazenados no Hard Disk (HD) do dispositivo e a partir do disco rígido o conteúdo é exibido. Justamente pelo vídeo ficar armazenado com o cliente este poderá copiá-lo e distribuí-lo, o que preocupa alguns produtores de conteúdo detentores de direitos autorais. Por esse motivo muitos preferem utilizar o streaming, que não armazena o vídeo de forma completa no HD do cliente (OZER, 2011a). O download progressivo também possibilita a distribuição de conteúdos audiovisuais codificados em altas taxas, pois caso o cliente tenha uma conexão a uma baixa taxa ele trocará um período de espera de download por uma melhor qualidade de imagem e som. Esta situação se assemelha ao streaming, porém uma vez que o vídeo estiver no HD 21

46 do cliente este poderá visualizá-lo novamente de seu dispositivo, enquanto no streaming o conteúdo que chega é diretamente visualizado e descartado (AUSTERBERRY, 2005b) Streaming adaptativo Além da questão dos direitos autorais, com a finalidade de evitar o problema de pausas na visualização do vídeo foi criado o streaming adaptativo. Por meio dessa técnica, o servidor disponibiliza para o usuário um mesmo conteúdo codificado em diferentes taxas. Desta forma o cliente poderá adaptar dinamicamente a taxa de transmissão do streaming (dentre as taxas disponíveis) de acordo com uma análise da banda disponível, situação do buffer, do processamento da Central Processing Unit (CPU) e o tamanho da tela de visualização (OZER, 2011b). Assim, com o streaming adaptativo o usuário terá a melhor experiência de qualidade de som e imagem possível, permitindo tanto uma televisão fullhd, como um celular de baixa resolução, exibirem o mesmo conteúdo, adaptado para cada situação. 3.2 Início do streaming adaptativo ao surgimento DASH Ozer (2011b) traz as principais alternativas de streaming adaptativo existentes, iniciando pela Move Networks, que foi a primeira a popularizar esta tecnologia em 2007 (MO- VENETWORKS, 2010). A Move chegou a ter em sua carteira de clientes a ABC.com e FOX.com, sendo uma referência de desenvolvimento da tecnologia. Porém alguns movimentos de mercado fizeram com que a Move deixasse de ser um dos players do mercado do streaming adaptativo. Lawler (2010), no portal da GigaOM, relata os principais motivos que levaram a Move Networks para esta situação. Um deles foi o fato de que os usuários deveriam ter um plug-in em suas máquinas para visualizar o conteúdo. Enquanto os computadores não tivesse este aplicativo a empresa não poderia abranger o mercado, porém enquanto a Move não abrangesse-o as pessoas não iriam instalar o plug-in, o que impediu todo o desenvolvimento. Outro fator foram os custos para implementar e ter acesso ao serviço exclusivo. O fato dos reprodutores da Move não terem compatibilidade com propagandas, preparadas para o Adobe Flash, contribuiu também para a queda da companhia. Ao tomarem conta das possibilidades do streaming adaptativo outras empresas, como a Adobe e a Microsoft, começaram a investir na tecnologia e em 2008 lançaram 22

47 suas plataformas de streaming adaptativo retirando definitivamente a Move do mercado das empresas de streaming (LAWLER, 2010). No ano de 2008, conforme citado no parágrafo anterior, a Adobe criou o Dynamic Streaming RTMP (Real Time Messaging Protocol), que requeria pelo menos um servidor Flash Media 3.5 (ou compatível) e utilizava o protocolo de distribuição RTMP. Tal solução possibilitou também o uso de codecs como VP6 e H.264 (OZER, 2011b). O sistema conseguiu ter uma ampla abrangência já que o Flash, no final de 2008, tinha uma penetração de 99% os computadores conectados à Internet (FLASH, 2008). No final do mesmo ano a Microsoft também lançou seu produto, o Smooth Streaming, que funcionava com o plug-in Silverlight e introduziu o uso do protocolo HTTP, em contraste ao RTMP (OZER, 2011b). O portal InternetNews.com trouxe a matéria em que Patrizio (2008) diz que no ano do lançamento do Silverlight um em cada quatro consumidores tinham acesso ao sistema da Microsoft. Em meados de 2009 a Apple lançou sua própria tecnologia, também utilizando HTTP, chamada HTTP Live Streaming (HLS) que é o único sistema que permite visualizar streaming em dispositivos com o ios da Apple, como o iphone e ipad (OZER, 2011b). Desta forma, tanto a Apple quanto a Microsoft, estavam apostando no uso do HTTP e não no RTMP (proprietário da Adobe) como protocolo de distribuição. Frente a essa realidade, a Akamai lança a sua HD Network, que utilizava uma Content Delivery Network (CDN) rede de servidores em lugares diferentes com informações replicadas, que aproximam a informação do consumidor. Esta rede conseguia converter arquivos RTMP para HTTP e disponibilizá-los para reprodutores Silverlight e dispositivos ios (OZER, 2011b). Percebendo que os concorrentes estavam investindo em sistemas HTTP, a Adobe lança, em 2010, o HTTP Dynamic Streaming, que compatibilizou o Flash Player ao HTTP, permitindo este receber conteúdos não advindos de servidores Flash Media (OZER, 2011b). Com esse breve panorama é possível perceber que as diversas formas de distribuição do conteúdo para streaming estão convergindo para a utilização do HTTP, por poder utilizar toda uma infraestrutura já presente na rede de Internet. Apesar de aparentar uma convergência entre os sistemas apresentados, na realidade esta se dá somente no uso do HTTP e na estrutura macro relacionada ao uso deste protocolo. Sodagar (2011), em seu paper na revista IEEE Multimedia, apresenta a realidade 23

48 entre cada uma das plataformas apresentadas. No artigo é evidenciado que para cada solução existem formatos próprios de arquivos, seja ele do tipo Manifest a ser explicado ainda neste tópico como nos segmentos do conteúdo. A incompatibilidade também se dá ao receber este conteúdo, que para cada tecnologia existem seus dispositivos e aplicativos específicos. Sodagar (2011) defende que um padrão para o HTTP Streaming iria possibilitar uma interoperabilidade entre diferentes tipos de servidores e clientes, diminuindo os problemas relacionados a compatibilidade. É neste cenário que surge o DASH (Dynamic Adaptive Streaming over HTTP), que tem como objetivo estabelecer um padrão para o streaming dinamicamente adaptativo sobre HTTP. O DASH tem sido desenvolvido em várias frentes, que se baseam uma nas outras, e de forma colaborativa amadurecem a tecnologia. O começo do desenvolvimento do DASH se deu em abril de 2009 com um grupo no 3GPP que iniciou um trabalho com o streaming HTTP, já que além da padronização, conforme citado por Lohmar et al. (2011), este grupo tinha interesse na convergência da rede de Internet com a de dispositivos móveis. Primeiramente foi lançado o Release 9, em março de 2010, contendo o 3GPP Adaptive HTTP Streaming (AHS). Após esse primeiro documento o Open IPTV Forum elaborou um documento com requerimentos para seu HTTP Adaptive Streaming (HAS), baseado no AHS da 3GPP. Baseado nessas duas especificações o Moving Picture Experts Group (MPEG) lançou seu documento, com o MPEG-DASH. Após todas essas contribuições espera-se o lançamento do Release 10 da 3GPP (STOCKHAMMER, 2011). 3.3 DASH - Abordagem técnica No início do capítulo foram discutidas as qualidades e deficiências entre as três principais formas de distribuição desses conteúdos. Como forma de unir esses três tipos, potencializando as qualidades de cada um, começou-se a ser utilizado o HTTP, como protocolo da camada de aplicação, para se transmitir o conteúdo de áudio e vídeo. Isso porque o HTTP possibilita o streaming adaptativo ao mesmo tempo que utiliza a grande rede de servidores web para distribuir seu conteúdo. Na seção anterior foi apresentado o panorama que convergiu os modelos de streaming também para a utilização do HTTP, que culmina com a padronização dessa forma de distribuição com o DASH. Essa seção trará, primeiramente, como que realiza-se a codificação fonte do conteúdo que será trans- 24

49 mitido em DASH. Por fim, serão abordadas as dinâmicas de funcionamento do DASH assim como a sua estruturação Codificação fonte: MPEG-2 Systems, compressão e empacotador DASH Para a codificação do DASH é possível utilizar diversos tipos de codificações de fonte. No caso dos testes realizados com o DASH nessa dissertação, o conteúdo estrutura-se de acordo com procedimentos do MPEG-2 Systems. O áudio foi codificado em MPEG-4 High Efficiency AAC v2 (HE-AAC v2) e os vídeos em MPEG-4 parte 10 /Advanced Video Coding (AVC) - H MPEG-2 systems Para que seja possível unir os fluxos de diferentes codificações fonte de áudio e vídeo em um único fluxo, juntamente com dados, existe uma padronização que descreve seu procedimento, conhecida como MPEG-2 systems. Essa especificação define um tipo de multiplexação que resultará em um Transport Stream (TS), que é a utilizada no ISDB-T B. Como início de análise do MPEG-2 systems toma-se o resultado da codificação fonte de um conteúdo de áudio e vídeo, chamado Elementary Stream (ES). O ES se caracteriza por ser um fluxo contínuo de bits, resultantes da compressão, compostos por access units, que são os trechos do conteúdo comprimido (SARGINSON, 1995). Na sequência, o ES será dividido em blocos chamados Packetized Elementary Stream (PES), com vistas a facilitar as próximas etapas, já que trata-se de um fluxo empacotado, não mais contínuo. Esses pacotes podem conter um ou mais access units, e terão tamanho variável, com payload máximo de 64 KBytes (SARGINSON, 1995). Assim, no caso de uma única programação contendo áudio e vídeo, haverá uma separação desses elementos, destinando-os para os seus respectivos processos de compressão, o que resulta em ES diferentes e separados, e por consequência, PES também distintos. Durante o processo de codificação haverá diferentes atrasos para cada codificação fonte, o que gera um problema de sincronismo. Como o áudio e o vídeo serão unidos novamente em um único fluxo, será necessário estampas para sincronismo no tempo, chamadas time stamps. Esses marcadores permitirão a manutenção da reprodução simultânea do áudio e vídeo, já que o decodificador poderá reproduzir ao mesmo tempo cada um dos PES 25

50 baseando-se nessas estampas. Assim, cada um dos PES conterá um payload de dados do ES fracionados sequencialmente, e um cabeçalho que incluirá estampas de tempo, para manter os pacotes PES de diferentes fontes sincronizados. Ressalta-se que para tal existirá um clock comum entre os codificadores. As estampas do tempo, para o PES, terão um número com 33 bits, baseado em um clock de 90 khz, que é a divisão do clock de 27 MHz por 300 (TEKTRONIX, 2011). A figura 10 traz como que se dá o encapsulamento do ES no PES. Figura 10: Empacotamento ES no PES. Fonte: Adaptado de Sarginson (1995, p. 4/4). As estampas de tempo do PES estarão no cabeçalho, sendo uma a Decoding Time Stamp (DTS) e outra a Presentation Time Stamp (PTS). A diferença entre essas duas estampas pode ser compreendida ao analisar as técnicas de compressão de vídeo, que podem ser bidirecionais, ou seja, consideram informações passadas e futuras para uma codificação de um dado presente. Assim, para que possa ser realizada a decodificação é necessário que na saída do compressor os dados sejam enviados fora da ordem temporal, para que todas as informações necessárias para decodificar uma informação estejam presentes no seu momento da decodificação. Por esse motivo existe uma estampa, chamada DTS, que indicará a ordem que deverá ser decodificado cada PES. Porém, a ordem de decodificação dos PES não serão as mesmas de reprodução do conteúdo. Assim, faz-se necessária a estampa PTS, que ordenará a reprodução dos PES. Ressalta-se que no caso do áudio não ocorre a transmissão do resultado da compressão fora da sequência, ou seja, não precisam da DTS (TEKTRONIX, 2011). 26

51 Uma vez estruturados os PES eles serão multiplexados em um fluxo chamado Transport Stream (TS). O tamanho dos pacotes desse fluxo (188 bytes, sendo 4 de cabeçalho e 184 de payload) normalmente serão menores do que os do PES, o que resulta em uma divisão de um pacote PES em diversos pacotes TS. Ao analisar a divisão de um fluxo PES em diversos pacotes TS obtêm-se a estrutura apresentada na figura 11, que mostra que no primeiro pacote TS existirá o cabeçalho do PES e parte de seu payload. No próximo pacote Transport Stream seguirão os demais trechos da parte de dados do PES, até que todas as partes completem um pacote PES inteiro, o que possibilitará o encapsulamento TS do próximo pacote PES. Porém, pode acontecer de esses trechos da divisão do pacote PES não resultem em um múltiplo de 184 bytes, ou seja, no último pacote TS existirá um espaço de seu payload sem dados do pacote PES, que será preenchido com um campo de adaptação, que incluirá valores nulos, chamados de stuffing bytes (SARGINSON, 1995). 4 Bytes (Cabeçalho TS) Cabeçalho PES Stuffing Figura 11: Método de inserção do PES no TS. Fonte: Adaptado de Takahashi (2007, p. 16). Porém, na realidade existe mais do que um único fluxo a ser multiplexado, portanto, os pacotes TS intercalarão os diferentes PES de entrada. Essa divisão no tempo será feita de forma coerente com as taxas de cada PES, ou seja, a divisão dos fluxos de entrada com maior taxa de bits serão presentes em maior frequência no payload do TS, do que os de menor taxa com menor frequência (NHK, 2002). A figura 12 ilustra um exemplo de como é feita a multiplexação de dois PES diferentes. Como no MPEG-2 Systems existem várias estampas de tempo para sincronismo há a 27

52 184 Bytes Cabeçalho PES 1 PES1 Cabeçalho PES 1 Cabeçalho PES Bytes TS 4 Bytes (Cabeçalho TS) Cabeçalho PES 2 PES2 184 Bytes Figura 12: Método de multiplexação do TS. Fonte: Adaptado de Takahashi (2007, p. 13). necessidade de um clock de referência, que derivará outros pulsos. Porém, é preciso que essa base esteja sincronizada no codificador e decodificador, para que trabalhem de forma síncrona. Para tal, existe um campo no cabeçalho do TS com um valor binário chamado Program Clock Reference (PCR). Esse valor, com 42 bits (com 33 bits de base em 90 khz e 9 bits de extensão em 27 MHz) traz amostras do clock do codificador fonte e será enviado periodicamente para o decodificador fonte, para que este verifique se sua base de trabalho local está igual a do codificador fonte. Caso exista um desvio, chamado jitter, o decoder irá ajustar o oscilador de referência local para que haja sincronismo correto (SARGINSON, 1995). Na prática também existe, no cabeçalho do TS um campo de identificação do tipo de conteúdo que está no payload, chamado Packet Identification (PID). Esse valor, de 13 bits, ajudará na identificação dos diversos dados que chegam ao demultiplexador no decodificador fonte. Assim, também é facilitada a separação dos diferentes PES pois eles conterão o mesmo PID (TEKTRONIX, 2011). Mas para que o decodificador fonte consiga relacionar os dados com seus respectivos PIDs é necessário que ele verifique essa 28

53 informação com o uso de tabelas, que são transmitidas regularmente no payload dos pacotes do TS (SARGINSON, 1995). Essas tabelas são chamadas de Program Specific Information (PSI) e algumas tem seu PID padronizado, o que permite que o decodificador já a encontre sem qualquer informação adicional. A partir dessas tabelas padronizadas é possível encontrar os valores de outros PIDs dos demais serviços dentro do TS. A tabela 6 traz um resumo das tabelas PSI, seus PIDs e funções (AKAMINE, 2012). Tabela 6: Program Specific Information (PSI) Nome da tabela PID Alocado Descrição Program Association Table (PAT) 0x00 Indica o PID da Program Map Table (PMT) Program Map Table (PMT) Indicado na PAT Especifica os PIDs dos serviços disponíveis Network Information Table (NIT) Indicado na PAT Traz parâmetros de rede como a frequência FDM Conditional Access Table (CAT) 0x01 Indica PIDs de dados encriptados Fonte: Adaptado de NHK (2002). Em resumo, um codificador fonte que tem como entrada um conteúdo de áudio e vídeo não comprimidos e como saída um TS seguirá todos os processos e características descritos, conforme o diagrama exposto na figura 13. MPEG2 Áudio ISO/IEC Áudio Codificador ES Empacotador de áudio MPEG2 Systems ISO/IEC PES MPEG2 Vídeo ISO/IEC Vídeo Codificador ES PES Empacotador de vídeo Multiplexador MPEG-2 TS TS Figura 13: Sistema de multiplexação do MPEG-2 Systems. Fonte: Adaptado de Takahashi (2007, p. 9). 29

54 Compressão do áudio: MPEG-4 HE-AAC A técnica utilizada no áudio, assim como o MPEG-4 parte 10, assume o conceito de fazer uma codificação baseada em objetos, tomando, por exemplo, cada canal de áudio como um objeto e estabelecendo relações entre eles, ao invés de analisar somente sua envoltória espectral (STOLFI, 2008). As principais melhorias do MPEG-4, em relação ao MPEG-2, estão no uso do Perceptual Noise Substitution (PNS) e na quantização vetorial. O primeiro fator citado basea-se na característica do ser humano não ter grande sensibilidade para diferenciar um ruído original de outro que foi sinteticamente produzido a partir das informações do contorno da envoltória do espectro do sinal original. Assim, ao se codificar um sinal utilizando PNS somente são enviadas as informações do contorno o espectro, cabendo ao decodificador criar um ruído que se adeque ao contorno recebido (AUSTERBERRY, 2005d). Outra técnica utilizada é a quantização vetorial que tem como objetivo representar uma distribuição de dados por meio de um novo conjunto, que se assemelha estatisticamente do original, porém com menor número de dados (VIO- LATO, 2010). Para Meltzer e Moser (2006) o MPEG-4 HE-AAC v2 tem como principal característica o uso de três técnicas para redução do número de bits. A primeira é o Advanced Audio Coding (AAC), que filtra o áudio em bandas, gera coeficientes espectrais e utiliza um preditor espectral que codifica as diferenças do espectro do sinal ao decorrer do tempo. Por fim, aplica-se a codificação de Huffmman com os coeficientes (STOLFI, 2008). A segunda técnica chama-se Spectral Band Replication (SBR) que baseia-se em enviar somente a banda de baixas frequências e informações sobre o envelope espectral da banda de altas frequências, que servirá para recompô-la no decodificador (MELTZER; MOSER, 2006). A terceira é o Parametric Stereo (PS), que diferencia o HE-AAC v2 do HE-AAC v1, que tem como princípio parametrizar a relação de diferenças de tempo e fase entre o canal esquerdo e o direito e enviar um sinal mono, que será a união de dois canais. Com essas informações, será viável para o receptor, depois de decodificar esse sinal, reconstruir o estéreo com os parâmetros coletados na técnica do PS (MELTZER; MOSER, 2006). 30

55 Compressão do vídeo: H.264 Para o vídeo foi utilizado o H.264 Advanced Video Coding (AVC) que trata-se de uma técnica de codificação de vídeo elaborada por um grupo chamado Joint Video Team (JVT). Esta equipe une o grupo da International Telecommunication Union (ITU), chamado Video Coding Experts Group (VCEG), com o grupo MPEG. Em 2003 publicou-se o padrão como ISO/IEC MPEG-4 parte 10 e ITU-T Recomendação H.264. Esse padrão apresentou uma vantagem em relação aos anteriores devido a sua alta capacidade de compressão. A qualidade de imagem obtida utilizando H.264 foi superior ao MPEG-2 utilizando a mesma taxa de bits. Sikora (1997) ressalta que outra característica do H.264 foi seu desenvolvimento, em 1994, para futuras aplicações multimídias, em ambientes heterogênios e para dispositivos móveis. Basicamente o H.264 tem três etapas principais: modelo temporal, modelo espacial e codificador entrópico, que serão sucintamente explicadas a seguir. O modelo temporal tem como tarefa reduzir a redundância temporal entre os quadros (VIANELLO, 2007). Esse fenômeno ocorre pois normalmente existe uma alta correlação entre os quadros subsequentes, pois parte deles se repete no seguinte, já que a câmera tende a ficar no mesmo enquadramento por mais do que um quadro. Assim, diversos elementos se repetirão, mantendo sua posição ou se movendo. O modelo temporal atuará justamente com essa caraterística do vídeo, aliando um preditor em seu processo (STOLFI, 2010). Ao detectar o deslocamento de objetos entre quadros o codificador irá enviar essa informação para o preditor na forma de vetores de movimento e com base neles o preditor fará a estimativa do quadro seguinte. Stolfi (2010) também nomeia a compensação de movimento como compensação por translação de blocos semelhantes, já que esses objetos da imagem são na realidade os blocos resultantes da divisão da imagem, que acontecem na entrada do sistema, conforme Schäfer, Wiegand e Schwarz (2003). O modelo espacial irá diminuir a redundância de informação na imagem, considerando as semelhanças entre pixels vizinhos (VIANELLO, 2007). Richardson (2003) explica que para tal, uma técnica utilizada no H.264 é aplicar uma transformada nas amostras do quadro residual. Assim, essas amostras estarão em outro domínio, representadas por coeficientes, que serão quantizados a fim de reduzí-los, desprezando alguns valores. A saída deste bloco serão coeficientes quantizados da transformada. Desta forma a quan- 31

56 tidade de informação será reduzida, pois alguns desses coeficientes já serão suficientes para caracterizar a imagem (RICHARDSON, 2003). Portanto, esse processo divide-se em transformação, que diminuirá a correlação dos dados, quantização, que reduzirá a precisão da transformada, e, por fim, reorganização dos dados em grupos. Por fim, a codificação entrópica será responsável pelo tratamento da informação do vídeo, para que ele seja armazenado ocupando menor espaço possível, assim como seja transmitido a uma menor taxa de bits viável (SIKORA, 1997). Para conquistar essa propriedade, esse processo explorará as redundâncias estatísticas dos dados vindos dos modelos explicados anteriormente para codificá-los utilizando o mínimo de informação. As amostras quantizadas dos coeficientes da transformada realizada no modelo espacial, juntamente com os dados dos vetores de movimento vindos do modelo temporal e metadados serão unidos para resultarem em um único fluxo de bits na saída. Antes dos dados irem para o codificador entrópico, o fluxo de entrada primeiramente será pré-codificado com um preditor. Depois serão aplicadas duas técnicas de codificação entrópica: Huffman modificada e codificação aritimética (RICHARDSON, 2003) Empacotamento MP4Box Na estruturação do DASH, após a codificação da fonte, os conteúdos de áudio e vídeo serão empacotados pelo MP4Box, com base no ISO base media file format da ISO/IEC (INTERNATIONAL ORGANIZATION FOR STANDARDIZATION; INTERNATIONAL ELECTROTECHNICAL COMMISSION, 2012a). Uma das habilidades desse tipo de pacote é conseguir dividir o conteúdo em diversos arquivos (CON- COLATO, 2005). Essa propriedade é interessante na codificação DASH pois permite a fragmentação do vídeo em pedaços, que serão solicitados na reprodução. O MP4 formatase em orientação por objetos, que são chamados box. Dentro de um arquivo MP4 existem boxes, que são estruturados de forma hierárquica e não existirá nenhum dado fora de algum box. Cada uma dessas caixas é estruturada em três partes: indicador do tamanho total (4 bytes), tipo do box (4 bytes) e dados (tamanho variável), conforme estrutura da figura 14 (ZHAO; GUAN, 2010). Os três principais tipos do MP4 são o ftpy, que é obrigatório e inserido sempre no início do arquivo MP4, o moov, que indica que o box em questão contém metadados, e o mdat, que marca o box que contém os dados de mídia (CHEN; WU, 2012). 32

57 Tamanho (4 Bytes) Tipo (4 Bytes) Dados Figura 14: Estrutura do box MP4. Fonte: Adaptado de Zhao e Guan (2010, p. 984). O arquivo criado trará separadamente os boxes com metadados e outros com a mídia. Os metadados indicarão o tipo do conteúdo (em um código de 4 bytes) e timestamples (CONCOLATO, 2005). Ressalta-se que os metadados e a mídia se correlacionam por estarem em um mesmo box, além das estampas de tempo. A figura 15 mostra como se estrutura esse tipo de arquivo. Arquivo mp4 moov trak trak Metadados - Filme Trilha de Vídeo Trilha de Áudio Mídia - Filme mdat Áudio Vídeo Áudio Vídeo Áudio Figura 15: Diagrama de estrutura do pacote mp4. Fonte: Adaptado de Concolato (2005, p. 10). Na figura 15 observa-se que a mídia e seus metadados estão em boxes diferentes. O cabeçalho dos metadados, moov, indica que este é um box de metadados da mídia. Nota-se que dentro desse box encontram-se separadamente os dados da trilha de vídeo e da trilha 33

58 de áudio, ambas com o cabeçalho indicando trak, que evidencia que o box traz informações de um único stream. No outro box encontra-se a mídia, indicada no cabeçalho por mdat, que indica que internamente ao box existirão os dados de mídia (CONCOLATO, 2005). Assim, de forma hierárquica um box é inserido dentro do outro, e identificados por seus cabeçalhos Estruturação do conteúdo e funcionamento do DASH O DASH foi normatizado com a ISO/IEC :2012. A norma tem o escopo de padronizar a estrutura do media presentation description (MPD), dos segmentos e as análises desses componentes pelo cliente (INTERNATIONAL ORGANIZATION FOR STAN- DARDIZATION; INTERNATIONAL ELECTROTECHNICAL COMMISSION, 2012b). A estrutura de abordagem do DASH está destacada pelos blocos mais claros da figura 16. Media Presentation no Servidor HTTP Media Presentation Description (MPD) Programa A Segmento Segmento Segmento Segmento Segmento Segmento Programa B Segmento Segmento Segmento Segmento Segmento Segmento Entrega MPD Entrega Segmentos Cliente DASH Controle Analisador MPD Analisador Segmento Cliente HTTP Media Player Figura 16: Escopo da norma ISO/IEC :2012. Fonte: Adaptado de Sodagar (2011, p. 64). O Dynamic Adaptive Streaming over HTTP é constituído de duas partes principais: o MPD e a media presentation, que são os segmentos do conteúdo. O arquivo MPD é chamado de arquivo manifest, caracterizado por dar a localização dos arquivos do conteúdo a ser visto e ouvido pelo streaming. Este arquivo, escrito em extensible markup language (XML), contém o endereço URL de cada trecho do áudio e vídeo disponibilizado no 34

59 servidor. Ao iniciar a sessão o cliente prontamente já faz a requisição deste arquivo, indispensável para o streaming no DASH. A manifest file pode ser considerada como uma lista telefônica, em que os nomes são os arquivos de mídia, e os números de telefone são as URLs de cada arquivo. O MPD deve ser organizado de forma hierárquica em relação ao conteúdo multimídia, de acordo com o estabelecido pela ISO/IEC :2012. A media presentation, que é o conteúdo a ser transmitido, é primeiramente dividida em períodos, que podem ser comparados a blocos. Como uma função prática, essa divisão em períodos pode ser utilizada para dividir um programa de TV para entrada de intervalos comerciais. O próximo degrau da hierarquia é a divisão desses períodos em grupos, que congregam tipos de mídia comuns, devido ao codec utilizado ou linguagem de áudio, por exemplo. Assim, um grupo pode conter um áudio em português e outro grupo conter uma audiodescrição. A próxima divisão hierárquica será a separação de cada grupo em representações. Elas se diferenciam por conter o mesmo conteúdo codificados em taxas diferentes. No exemplo dado, seria como ter uma representação com o áudio em português a 128 kbps e outra com o mesmo conteúdo a 192 kbps. Por fim, a última partição da hierarquia se dá ao dividir cada representação em segmentos, que são propriamente os pedaços dos arquivos de áudio e vídeo. Para cada pedaço desse, chamado segmento, haverá uma URL associada. São esses endereços que irão para a MPD. A figura 17 mostra a hierarquia do MPD. Toma-se, na tabela 7, um exemplo real de uma MPD gerada nos testes do DASH, a serem apresentados no penúltimo capítulo dessa dissertação. O arquivo será interrompido em alguns pontos para identificação dos blocos. 35

60 MPD Período 1 Início = 0s Período 2 Início = 30s Período 3 Início = 60s Período 4 Início = 90s Período 3 Início = 60s Grupo 1 Grupo 2 Grupo 3 Grupo 1 Representação 2Mbps Representação 3Mbps Representação 6Mbps Representação 9Mbps Representação 3Mbps Segmento Inicial Segmento Mídia início = 0s Segmento Mídia início = 10s Segmento Mídia início = 20s Figura 17: Hierarquia da MPD pela ISO/IEC :2012. Fonte: Adaptado de Sodagar (2011, p. 65). 36

61 Tabela 7: MPD gerada nos testes do DASH. Cabeçalho: <?xml version="1.0"encoding="utf-8"?> <MPD xmlns:xsi=" xmlns="urn:mpeg:mpegb:schema:dash:mpd:dis2011" xsi:schemalocation="urn:mpeg:mpegb:schema:dash:mpd:dis2011" profiles= "urn:mpeg:mpegb:profile:dash:isoff-basic-on-demand:cm" type="ondemand" mediapresentationduration="pt5m0.08s" minbuffertime="pt10.00s <Period> Identificação do tipo de mídia: <Group segmentalignmentflag="true"mimetype="video/mp4 <Representation mimetype="video/mp4"width="1280"height="720" startwithrap="true"bandwidth= "317880"minBufferTime="2000 Identificação da duração dos pedaços da mídia: <SegmentInfo duration="pt2.00s Identificação do arquivo inteiro do vídeo, para a primeira taxa: <InitialisationSegmentURL sourceurl=" DASH/ zp1 t1t2t3/zp1 t1t2t3 1438kbit/ZonePlate 10M 20ponto02 24fps 720p/ new 1438kbit dash.mp4"/> Identificação sequencial dos pedaços do vídeo para a primeira taxa: <Url sourceurl=" DASH/PosBanca/ zp1 t1t2t3/ zp1 t1t2t3 1438kbit/zp1 t1t2t31.m4s"/> [...] <Url sourceurl=" DASH/PosBanca/ zp1 t1t2t3/ zp1 t1t2t3 1438kbit/zp1 t1t2t391.m4s"/> Início do bloco de identificação do vídeo na segunda taxa: </SegmentInfo> </Representation> <Representation mimetype="video/mp4"width="1280"height="720" startwithrap="true"bandwidth= "318061"minBufferTime="2000 <SegmentInfo duration="pt2.00s Identificação do arquivo inteiro do vídeo, para a segunda taxa: <InitialisationSegmentURL sourceurl=" DASH/ PosBanca/ zp1 t1t2t3/zp1 t1t2t3 1845kbit/ ZonePlate 10M 20ponto02 24fps 720p new 1845kbit dash.mp4"/> Identificação sequencial dos pedaços do vídeo para a segunda taxa: <Url sourceurl=" DASH /PosBanca/zp1 t1t2t3/zp1 t1t2t3 1845kbit/zp1 t1t2t31.m4s"/> [...] <Url sourceurl=" DASH /PosBanca/zp1 t1t2t3/zp1 t1t2t3 1845kbit/zp1 t1t2t391.m4s"/> </SegmentInfo> </Representation> </Group> </Period> </MPD> 37

62 Ao realizar uma transmissão baseada em DASH utiliza-se a estrutura de servidor e cliente. Para realizar o streaming, o conteúdo a ser disponibilizado será separado em pequenos trechos e codificado em diferentes taxas, para viabilizar o streaming adaptativo. Cada pequeno trecho será armazenado no servidor, sendo a ele associado uma URL. Uma vez que o cliente tem o arquivo MPD o usuário poderá solicitar, através do método HTTP GET, cada segmento desejado. Ressalta-se que o primeiro segmento dentro de cada representação conterá metadados sobre a codificação dos próximos segmentos, que trarão o conteúdo de áudio e vídeo propriamente dito (MÜLLER; TIMMERER, 2011). Desta forma, o controle do streaming será, de forma completa, uma tarefa do usuário, que fará o acompanhamento da qualidade de processamento e da rede. Assim, de acordo com a análise realizada, o cliente poderá pedir uma outra representação, com segmentos codificados em uma taxa maior ou menor, uma resolução diferente ou até mesmo outra proporção da tela de visualização (STOCKHAMMER, 2011). Na tabela 8 é apresentado um exemplo, acontecido nos testes, das requisições HTTP do reprodutor para o servidor, solicitando pedaços do conteúdo DASH. Tabela 8: Requisições HTTP do cliente para o servidor DASH [04/Dec/2013:19:55: ] GET /Arquivos DASH/ 8ave t1t2t3/8ave t1t2t3 1438kbit/8ave t1t2t328.m4s HTTP/1.1" [04/Dec/2013:19:55: ] GET /Arquivos DASH /8ave t1t2t3/8ave t1t2t3 1438kbit/8ave t1t2t329.m4s HTTP/1.1" [04/Dec/2013:19:55: ] GET /Arquivos DASH /8ave t1t2t3/8ave t1t2t3 1438kbit/8ave t1t2t330.m4s HTTP/1.1" [04/Dec/2013:19:55: ] GET /Arquivos DASH /8ave t1t2t3/8ave t1t2t3 1845kbit/8ave t1t2t331.m4s HTTP/1.1" Para que um conteúdo seja codificado e estruturado em DASH é preciso que ele passe por todas as etapas do diagrama de blocos representado na figura 18. Portanto, a primeira etapa será tomar o media presentation, que é o conteúdo a ser disponibilizado em DASH, e dividí-lo em pedaços de um tamanho fixo, como por exemplo dois segundos. Linearmente esse processo é realizado até o final da mídia. Depois dessa etapa cada pedaço será codificado em taxas pré-estabelecidas, o que resulta em várias cópias dos pedaços da mesma mídia, porém com taxas diferentes. Ressalta-se que nessa 38

63 C B A Divisão Pedaços fixos Codificação Pedaços Organização URL e MPD E D C A B Servidor MPD Figura 18: Diagrama de blocos do DASH. etapa poderá ser escolhido diversos tipos de técnicas de codificação, como, por exemplo, o H.264. A última etapa será organizar todos os trechos e gerar uma lista de seus endereços, chamada MPD. Todo esse conteúdo será, por fim, disponibilizado no servidor. Ao se aplicar os conceitos básicos descritos no início deste capítulo surge um conflito na nomenclatura DASH relacionado ao uso da palavra streaming juntamente com HTTP. Stockhammer (2011) explica que no streaming tradicional normalmente os protocolos da camada de aplicação, do modelo OSI, são orientados ao estabelecimento de sessão, como o RTSP e RTP/RTCP. Nesta situação, o cliente se conecta ao servidor e uma sessão é mantida em aberta para toda a troca do conteúdo, até que o cliente solicite o fim da sessão. Porém o HTTP é considerado sem status, pois para cada dado trocado uma sessão é estabelecida e finalizada, não guardando um histórico das trocas de mensagem entre cliente e servidor. Desta forma pode-se dizer que o DASH não se trata de um streaming tradicional, já que seu protocolo não é orientado por sessões. Inclusive o protocolo HTTP está ligado ao uso de servidores web, que por sua vez estão relacionados ao streaming progressivo. O DASH é um streaming baseado em HTTP, que será muito similar ao download progressivo, porém levando em consideração as deficiências deste tipo de tecnologia. Dentre os principais pontos de melhoria em relação ao download progressivo estão o uso desnecessário da banda que acontecerá no caso de alguém requisitar vídeo, iniciar seu download integral 39

64 e decidir não vê-lo mais. Esta forma de entrega também não permite uma adaptação da taxa, assim como não suporta a transmissão de eventos ao vivo, já que o arquivo deverá estar pronto integralmente para sua transmissão (STOCKHAMMER, 2011). Estes foram os principais pontos que os desenvolvedores do DASH procuraram trabalhar, criando um download progressivo com as vantagens do streaming adaptativo. Begen (2011) afirma que o DASH é um sistema híbrido, pois imita o streaming através de pequenos downloads. 40

65 4 CONCEITOS DE REDES IP APLICADOS AO STREAMING Este capítulo traz os conceitos necessários para compreender como se dá a inserção dos dados, já comprimidos, no ambiente do internet protocol (IP), assim como as dinâmicas desse ambiente ao abordar as camadas de sua estrutura, com foco nos protocolos voltados para a realização do streaming. Basicamente os dados digitalizados e comprimidos serão gerenciados por uma aplicação que realizará o streaming do conteúdo. Essas informações serão passadas para uma camada chamada transporte que fará o controle da transmissão desses dados, como garantia de entrega e multiplexação e demultiplexação dos dados de diversas aplicações. Depois, todos esses dados serão passados para a camada de rede, que fará o encapsulamento IP para que eles sejam reconhecidos em uma rede de Internet, que distribuirá, pela camada de enlace, esses dados para vários terminais. Nesses receptores será feito o processo inverso, até que os dados cheguem na aplicação de streaming, na reprodução do conteúdo. Esse processo de streaming pode ter como paralelo o sistema ISDB-T B, apresentado na figura 1. A etapa de codificação em comum já foi abordada no terceiro capítulo deste trabalho, e estará na camada de aplicação. O próximo bloco, multiplexador, será a camada de transporte, com os protocolos UDP e TCP. O modulador será responsável por adequar esses dados a um ambiente de transmissão, portanto o paralelo com o streaming se dá no bloco do encapsulamento IP. Por fim, o amplificador e a antena, estão na camada física das redes IP, que são os cabos UTP, fibras ópticas, ou até mesmo amplificadores e antenas específicas para transmissão IP. Esse comparativo é mostrado na figura 19. A estrutura e processos de cada etapa serão explicados com maiores detalhes nas próximas sessões. Porém antes de abordar esses assuntos é necessário compreender como se estruturam os processos entre protocolos e camadas de arquiteturas de rede, baseadas nos modelos Open Systems Interconnection (OSI) e Transmission Control Protocol/IP (TCP/IP), explicados na primeira sessão. Depois as sessões do capítulo farão uma abor- 41

66 Figura 19: Comparativo dos blocos ISDB-T B com o streaming. Fonte: Adaptado de ABNT (2007, p. 4). dagem da camada mais baixa até chegar na aplicação streaming. Vale ressaltar, somente, que não se abordará a camada de enlace, pois ela se trata de uma camada mais próxima da física e seu estudo voltaria essa monografia a uma análise técnica de camadas físicas de rede, o que não faz parte do escopo deste trabalho. Pretende-se aqui abordar as especificidades da rede relacionadas ao streaming, que são diferentes em relação a transmissão de outros tipos de dados, como e transferência de arquivos. Assim as sessões, após a apresentação dos modelos, serão sobre a camada de rede, com o encapsulamento IP, a camada de transporte, com seus principais protocolos e, por fim, a camada de aplicação, com a exposição dos protocolos utilizados para o streaming. 4.1 MODELOS OSI E TCP/IP Ao realizar uma análise em arquiteturas de rede existem dois modelos muito utilizados como referência: o modelo OSI e o TCP/IP. O primeiro, desenvolvido pela International Standards Organization (ISO), evidencia em seu nome que a intenção em elaborá-lo foi em padronizar uma interconexão de sistemas diferentes. Assim, esse modelo tem como foco os conceitos da divisão de suas camadas e não os protocolos inseridos nelas. De forma diferente foi criado o modelo TCP/IP, que se baseia em um grupo de protocolos já existentes antes de sua elaboração, adequando sua divisão de camadas a esses protocolos (TANENBAUM; WETHERALL, 2010). Dada tal realidade, o modelo OSI pode ser con- 42

67 siderado como referência genérica de uma arquitetura de rede, pois ele traz conceitos de cada etapa do processo. Mas ao tentar definir alguns protocolos dentro de suas divisões foram percebidas incompatibilidades (TANENBAUM; WETHERALL, 2010). Nesse ponto que o modelo TCP/IP traz uma grande relevância em seu uso no estudo de arquiteturas de rede para Internet, pois ele foca e engloba os principais protocolos utilizados nesse tipo de estrutura. A seguir são explicadas as funções de cada camada dos dois modelos, para que a partir do OSI se compreenda o TCP/IP, pois baseando-se em suas camadas será explicado o processo para se realizar um streaming Modelo OSI O modelo OSI é subdivido em sete camadas, que podem ser divididas em três grupos: aplicação, transporte e rede (TORRES, 2001), conforme se pode observar na figura 20. No primeiro grupo estão as camadas que lidam com o uso dos dados por determinado programa. Esses dados terão garantia de transmissão e recepção pelo último grupo e o transporte será responsável pela conexão entre os grupos de aplicação e de rede. O grupo de aplicação, juntamente com o de transporte englobam as camadas que fazem uma conexão entre as duas pontas da comunicação, já que o grupo de rede se atém à comunicação entre equipamentos adjacentes durante o caminho da informação (TA- NENBAUM; WETHERALL, 2010). Cada camada presente nesses grupos é brevemente explicada a seguir. 7 Aplicação 6 Apresentação 5 Sessão 4 Transporte 3 Rede 2 Enlace de dados 1 Física } Grupo de Aplicação } } Grupo de Transporte Grupo de Rede Figura 20: Camadas do modelo OSI. Fonte: Adaptado de Torres (2001, p. 42). 43

68 Camada de aplicação Esta é a camada mais próxima da interação do usuário. Ela é responsável por suportar os processos que envolvem os dados dos aplicativos em execução como transferência e gerenciamento da demanda de recursos (BARRETT; KING, 2010) Camada de apresentação Esta tem a função de capturar os dados da camada de aplicação e organizá-los para transmití-los em algum padrão, por isso também é chamada de camada de tradução. Esse formato poderá ser uma compactação com ou sem criptografia, o que pode reduzir a quantidade de informação a ser transmitida pelas camadas abaixo (TORRES, 2001) Camada de sessão Trata-se da camada responsável por manter a comunicação entre as aplicações. Ela faz a mediação da sessão, com o monitoramento do diálogo entre as aplicações, gerenciando a entrada de novos componentes, troca de informações e finalização da conversa (BARRETT; KING, 2010) Camada de transporte Esta camada toma os dados da camada acima (sessão) e os divide em pacotes para que eles possam ser enviados pela camada de rede. A camada de transporte atenta para que a entrega dos pacotes para a camada de sessão seja feita na ordem correta e sem erros. Outra característica presente na camada de transporte é o estabelecimento de um serviço orientado a uma conexão ou não, que varia de acordo com o protocolo utilizado. No primeiro caso haverá uma abertura de conexão para depois haver a troca de dados e finalmente se encerrar a conexão. Protocolos orientados à conexão oferecem garantias de entrega dos pacotes, porém com uma maior troca de informações entre as pontas, o que gera um maior tráfego. Em compensação o outro tipo de orientação não terá o trabalho de abrir e fechar conexões, mas nem sempre garante recibo de entrega dos dados (BARRETT; KING, 2010). 44

69 Camada de rede A principal tarefa desta camada é o roteamento dos pacotes nas redes, da origem até o destino. Para que isso seja possível são criadas rotas entre os nós da rede até que se alcance o destinatário. O controle desse tráfego, que pode ficar congestionado em alguns trechos do caminho,também é realizado pela camada de rede (TANENBAUM; WETHERALL, 2010) Camada de enlace de dados O enlace organiza os dados para serem transmitidos por uma rede. As informações são dispostas em quadros, que são conjuntos de dados agrupados e rotulados de acordo com endereço físico real da placa de destino correspondentes ao IP destinatário (TORRES, 2001) Camada física Esta é a camada que fisicamente levará o sinal elétrico (ou mesmo óptico) de um ponto ao outro. Ela é responsável por formatar, por exemplo, o período, amplitude e frequência do sinal que representará os bits 0 e 1, para que eles sejam transmitidos por um meio de comunicação. Também são padronizados os tipos de conectores e função de cada pino (TANENBAUM; WETHERALL, 2010) Modelo TCP/IP O modelo TCP/IP é dividido em quatro camadas: enlace, Internet, transporte e aplicação. Tal arquitetura surgiu com a antecessora da Internet, chamada ARPANET. Esse foi um projeto do Departamento de Defesa dos Estados Unidos e tinha que operar em diferentes tipos de redes (satélite, linha telefônica, rádio etc.) e manter a comunicação entre origem e destino mesmo que algumas conexões fossem perdidas (TANENBAUM; WETHERALL, 2010). Para que isso fosse possível foi necessário criar um modelo que ficou conhecido por TCP/IP. A figura 21 demonstra uma comparação das camadas dos modelos OSI e TCP/IP. 45

70 Modelo OSI 7 Aplicação 6 Apresentação 5 Sessão 4 Transporte 3 Rede 2 Enlace de dados 1 Física Modelo TCP/IP Aplicação Ausente Ausente Transporte Internet Enlace de dados Ausente Figura 21: Comparação entre camadas do modelo OSI e TCP/IP. Fonte: Adaptado de Tanenbaum e Wetherall (2010, p. 28) Camada de enlace Tem como responsabilidade manter a interligação da comunicação independente da conexão. Um dos requisitos é que exista uma interoperabilidade entre topologias e tecnologias de rede diferentes (TANENBAUM; WETHERALL, 2010) Camada de Internet Correlaciona-se com a camada de rede do modelo OSI, responsável por fazer o roteamento dos pacotes no destino. Para que isso seja possível foi padronizado um protocolo chamado IP juntamente com o Internet control message protocol (ICMP) (TANENBAUM; WETHERALL, 2010) Camada de transporte Tem a mesma função da camada que traz este mesmo nome no modelo OSI. No modelo TCP/IP foram definidos dois tipos principais de protocolos desta camada: o TCP e o user datagram protocol (UDP). O primeiro tem garantia de entrega dos pacotes, pois devolve um recibo de recebimento do dado, é orientado a conexão e administra o fluxo entre as pontas da conexão. Já o UDP não se orienta à conexão e não traz garantia de entrega dos pacotes bem como sua ordem de chegada. Ele é utilizado quando a garantia de entrega de todos os pacotes tem menos importância do que entregá-los o mais rápido possível, como a transmissão de áudio e vídeo (TANENBAUM; WETHERALL, 2010). 46

71 Camada de aplicação Esta camada engloba a camada de sessão, apresentação e aplicação do modelo OSI. Entre os protocolos presentes na camada de aplicação está o HTTP, que é responsável pelo streaming de soluções como o DASH, que se configura o estudo de caso desta dissertação (TANENBAUM; WETHERALL, 2010). 4.2 CAMADA DE REDE: ENCAPSULAMENTO IP Uma vez abordados os modelos OSI e TCP/IP, é possível versar sobre o encapsulamento IP. Nessa etapa são organizados os datagramas, pacotes compostos pelos dados a serem transmitidos juntamente com um cabeçalho. No caso do streaming, o áudio e vídeo já comprimidos serão parte dos dados úteis que terão como anexo o cabeçalho IP em sua sequência de bits, ou seja, eles serão encapsulados no ambiente IP. Essa adição feita aos dados visa que esses pacotes trafeguem em uma rede para seu destino por um trajeto conhecido com roteamento (INTERNET ENGINEERING TASK FORCE, 1981a). O roteamento se baseia em um endereçamento lógico padronizado pelo protocolo IP, chamado endereço IP, que terá sua estrutura explicada a seguir. Porém, o cabeçalho IP adicionado aos dados úteis não se resume ao endereço IP, mas inclui também outras informações, que serão explicadas na sequência do endereçamento Endereçamento IP A estrutura em uso é a versão 4 (IPv4), composta por endereços com 32 bits, porém devido ao crescente número de usuários da Internet está em implantação a versão 6 (IPv6) com 128 bits (TORRES, 2001). O endereço IPv4 é representado por quatro números, em base decimal, que representam cada um dos quatro bytes dos 32 bits do endereço, separados por.. Assim, existe a possibilidade de endereços de até Subdividiu-se todos esses endereços em cinco classes, caracterizadas pelo seu primeiro byte, conforme a tabela 9. Barrett e King (2010) ressaltam que para a classe A o primeiro byte tem o endereço 0 como inválido e o 127 é reservado, o que diminui os endereços de 1 até 126. Os autores também explicam que a classe D foi reservada para uso futuro, porém tem seu uso atual para transmissões em multicast e a classe E é reservada para fins experimentais. 47

72 Tabela 9: Classes de endereços IP. Classe Faixa inicial Faixa final Padrão binário do primeiro byte A 0.x.x.x 127.x.x.x a B 128.x.x.x 191.x.x.x a C 192.x.x.x 223.x.x.x a D 224.x.x.x 239.x.x.x a E 240.x.x.x 255.x.x.x a Fonte: Barrett e King (2010). Pode-se afirmar que essa divisão de classes trata-se também de uma divisão de redes. Isso porque o endereço IP pode ser dividido em duas partes: uma que identifica a rede e outra um dispositivo na respectiva rede. A determinação prática dessa divisão é realizada pela máscara de sub-rede, que é uma sequência de quatro bytes representados identicamente a forma de representação do endereço IP. Para que seja identificada em um endereço IP a porção do endereço da rede e do dispositivo é realizada a operação AND 1. Pode ser aplicado esse conceito nas classes A, B e C definindo-se as máscaras para a classe A, para a classe B e para a classe C (TORRES, 2001). Dois exemplos de resultados obtidos são apresentados na tabela 10, que representa em negrito a parte do endereço IP que define a rede. O resto do endereço IP (que não está em negrito) será a parte que endereça os dispositivos dessa rede. Tabela 10: Máscara de sub-rede: divisão pela operação AND. Classe A Endereço de origem Máscara de sub-rede Resultado AND 170.x.x.x Classe C Endereço de origem Máscara de sub-rede Resultado AND x Fonte: Barrett e King (2010). Nota-se que a classe A possibilita a definição de um maior número de terminais conectados dentro de uma única rede ( dispositivos = 2 24 ) já que são atribuídos 8 bits para a rede e 24 para endereços de terminais, enquanto a classe C pode definir endereço para um menor número (256 dispositivos = 2 8 ) atribuindo a rede e terminais o número 1 Na álgebra booleana AND sempre que houver um bit 0 envolvido o resultado será 0, caso exista a operação entre dois bits 1 o resultado será o bit 1. 48

73 de bits inverso aos da classe A (BARRETT; KING, 2010). A figura 22 traz a atribuição dos bits para todas as classes. Classe A ID Rede Classe B ID Rede Classe C ID Rede Classe D Endereçamento Multicast Classe E ID Terminais ID Terminais Reservado uso futuro ID Terminais Figura 22: Atribuição dos bits para classes de endereçamento IP. Fonte: Adaptado de Torres (2001, p. 71). A máscara de sub-rede também é utilizada no roteamento entre redes diferentes, conectadas por um, ou mais, roteadores, que é um elemento de rede responsável por gerenciar o tráfego de pacotes IP em uma rede local e entre redes. Isso ocorre quando um pacote, por exemplo, de uma rede A (170.5.x.x) é enviado para uma rede B (160.3.x.x). Nessa situação quando o cliente A enviar um pacote de origem do terminal (máscara ) com destino ao (mesma máscara) ele irá comparar o resultado da porção de rede utilizando a operação AND de cada IP e a sua máscara de sub-rede. Caso o resultado seja diferente, significará que o destino está em outra rede e o pacote será enviado ao roteador, que fará a ponte para a outra rede. Caso as máscaras de sub-rede sejam diferentes, o pacote será enviado diretamente para o roteador, pois trata-se de redes diferentes (BARRETT; KING, 2010). A estrutura do exemplo, acima descrito, é representada pela figura 23. Além da divisão da porção de rede e de terminais apresentada, também é possível subdividir a rede em sub-redes, o que criará a possibilidade de tráfego entre terminais 49

74 Terminal A IP Máscara Terminal B IP Máscara Roteador Figura 23: Roteamento entre duas redes IP. Fonte: Adaptado de Barrett e King (2010, p. 204). dentro de uma rede menor, sem a necessidade de passagem desses dados por toda uma rede maior. Com essa divisão o remetente conseguirá saber se o destinatário está próximo a qual roteador, ou se ele está fisicamente próximo. Assim, ele pode julgar se é necessário, ou não, trafegar por um link entre sub-redes para chegar no destino. Isso porque muitas vezes essa divisão em sub-redes pode identificar as filiais de uma rede de uma empresa. Além da localização geográfica de unidades os pacotes poderão ter um encaminhamento mais eficiente com a informação de sub-rede, já que pelo endereço mais restrito não haverá necessidade de um pacote ir para um rede mais ampla para ser roteado para um terminal que está próximo ao remetente. A configuração de sub-redes pode ser feita a partir uma alteração na máscara de sub-rede, ao emprestar um bit (ou mais) da porção do endereço destinado aos terminais. Desta forma o endereço IP terá uma porção de identificação da rede, outra da sub-rede e o resto dos terminais. Pode-se esclarecer melhor essa técnica com a análise do código binário do endereço de dois terminais, no qual o primeiro caso traz a máscara sem a subdivisão, onde ambos terminais estão na mesma rede. Depois, com a alteração da máscara de sub-rede, o mesmo endereço IP dos terminais configurarão sub-redes diferentes. Essas duas situações são apresentadas pela tabela 11. Na tabela 11 percebe-se que a quantidade de bits 1 da máscara de sub-rede não tem a necessidade de englobar bytes inteiros. Justamente essa extrapolação é que dividirá a rede em pedaços, com o empréstimo de bits da porção dos terminais. Assim, a primeira sub-rede irá do endereço até e a segunda sub-rede do endereço até , dividindo a rede em duas sub-redes ao emprestar um bit. 50

75 Tabela 11: Divisão de sub-redes. Sem sub-rede Máquina 1 Endereço IP Máscara Resultado AND x.x Máquina 2 Endereço IP Máscara Resultado AND x.x Com sub-rede Máquina 1 Endereço IP Máscara Resultado AND x Máquina 2 Endereço IP Máscara Resultado AND x Fonte: Barrett e King (2010). Caso sejam emprestados mais bits a quantidade de sub-redes irá se alterar, conforme a tabela 12. Tabela 12: Quantidade de sub-redes em relação ao empréstimo de bits. Bits emprestados na máscara Redes criadas Fonte: Barrett e King (2010). Visto como se dá a estrutura do endereçamento IP, é possível apresentar como é realizado o roteamento de um pacote IP entre origem e destino. Esse serviço é realizado não somente devido à presença dos endereços, mas também outros dados presentes no cabeçalho, que serão explicados a seguir Cabeçalho IP Juntamente com o endereço IP de origem e destino, são adicionadas outras informações ao payload (dados úteis a serem transmitidos, como áudio e vídeo) com o intuito de facilitar o roteamento. Todos esses dados adicionados estarão em um cabeçalho, que no datagrama IP terá de 20 a 24 bytes, enquanto o payload pode conter até ou bytes. A 51

76 estrutura do cabeçalho do datagrama IP é padronizada pela Internet Engineering Task Force (1981a) e será explicada baseando-se na request for comments (RFC) 791, conforme a estrutura apresentada na figura 24, que mostra a distribuição das funções dos bits do cabeçalho. Figura 24: Distribuição dos bits do cabeçalho do datagrama IP. Fonte: Adaptado de Internet Engineering Task Force (1981a, p. 11) Versão Nos quatro primeiros bits será indicada a versão do IP. Caso o datagrama esteja na versão 4 esse campo mostrará o número quatro em binário (0100) e caso seja a versão 6 o campo trará o número seis (0110) Internet header length (IHL) Em seguida quatro bits indicarão o tamanho do cabeçalho, representando-o a quantidade words de 32 bits presentes. Esse campo recebe o nome de IHL Tipo de serviço O próximo byte apresenta nos três primeiros bits se a procedência é de controle de rede e nos restantes pode-se inserir fatores de qualidade de serviço, como indicação da relevância de atraso, taxa de transferência e confiabilidade Tamanho Total Na sequência, é identificado, em 16 bits, o tamanho total do datagrama, computando-o em número de bytes. 52

77 Identificação Em continuidade, 16 bits serão responsáveis por identificar um rótulo dado ao remetente no ato da transmissão, para facilitar na identificação dos datagramas que serão fragmentados na transmissão Flags A fragmentação também usará os próximos três bits, conhecidos como flags, em que o primeiro sempre será 0, e os seguintes indicarão se o datagrama foi ou não fragmentado e se existem outros fragmentos após o atual ou se ele é o último Offset do segmento Também para o controle da fragmentação, os próximos 13 bits indicarão a ordem de cada fragmento do datagrama, com o primeiro fragmento rotulado como zero e os próximos medidos em bytes Time to live (TTL) Em continuidade, um byte indicará o tempo de vida do datagrama. No momento que este valor chegar a zero o datagrama será descartado. O tempo é medido em segundos e pode ser decrescido após a passagem em cada módulo de rede. Esse byte de TTL é importante para que dados perdidos não continuem por muito tempo na rede, o que poderia causar um congestionamento Protocolo O byte seguinte do TTL identifica, com números tabelados, para qual protocolo de transporte os dados serão entregues Checksum do cabeçalho Para a verificação se os datagramas foram corrompidos na transmissão os próximos 16 bits realizarão a operação de checksum, que é somar os valores somente do cabeçalho e gravar esse resultado nestes 16 bits. O algoritmo utilizado é guardar o valor desse campo e depois atribuir 0 aos seus 16 bits. Depois são agrupados todos os bits em palavras 53

78 (16 bits) e somados os valores binários de todas elas. Por fim, toma-se o resultado e realiza-se o complemento de um (invertendo bits 0 por 1 e vice-versa) e compara ao valor gravado antes de zerar o campo. Caso ele seja igual à conta realizada, o pacote não está corrompido. Como existe uma dinamicidade em alguns valores do header, essa soma é recalculada constantemente. Como exemplo do cálculo do checksum, para envio do datagrama, será considerado um cabeçalho IP com 24 bytes. Primeiramente é necessário agrupá-los em words de 16 bits, atribuindo (0x0000) no campo do checksum, conforme explicitado na tabela 13: Tabela 13: Agrupamento em words. 0x46d0 0xf302 0xf3f8 0xf7f2 0x3d8a (0x0000) 0xc0a8 0x010b 0xc0a8 0x0172 0xf8f1 0xf300 O próximo passo é realizar a somatória de todas as words, contando com o checksum, que foi zerado. No caso do exemplo o resultado da somatória é 6d304. Para que o resultado continue sendo uma word de 16 bits soma-se o carryover ao resultado, conforme tabela 14. Tabela 14: Somatória das words. 0x d x x d 3 0 a Por fim toma-se o resultado do passo anterior, 0xd30a, e aplica-se o complemento de 1 tomando como resultado os últimos 16 bits. Esse procedimento resulta no valor final de 0x2cf5, que substituirá o 0x0000 inserido no campo no início do algoritmo. Assim o cabeçalho IP que irá para a camada inferior será o expresso na tabela 15. Tabela 15: Cabeçalho IP final. 0x46d0 0xf302 0xf3f8 0xf7f2 0x3d8a (0x2cf5) 0xc0a8 0x010b 0xc0a8 0x0172 0xf8f1 0xf300 No receptor do datagrama será feito exatamente o mesmo procedimento e o resultado final a ser obtido será 0x0000 caso todos os bits sejam recebidos corretamente, conforme demonstrado na tabela 16: 54

79 Tabela 16: Cabeçalho IP no receptor. 0x46d0 0xf302 0xf3f8 0xf7f2 0x3d8a (0x2cf5) 0xc0a8 0x010b 0xc0a8 0x0172 0xf8f1 0xf300 O resultado da somatória será 0x6fff9. O próximo passo será manter o resultado em uma word de 16 bits, somando-se o carryover, conforme tabela 17. Tabela 17: Cálculo da somatória no receptor. 0x f f f 9 0x x f f f f Ao resultado 0xffff aplica-se o complemento de 1, o que resulta em 0x0000, portanto, os bits recebidos estão corretos. Pode ser que ocorra um erro na transmissão e, por exemplo, os dois últimos bytes do IP do destino sejam alterados, fazendo com que o datagrama flua para o terminal com IP (0xc0a8 0x0101), ao invés do (0xc0a8 0x0172). Nesse caso, o terminal receptor detectará que o pacote não foi destinado à ele pois o valor do checksum não terá como resultado, após o algoritimo de verificação, o valor hexadecimal de 0x0000, conforme demonstrado na tabela 18, com a nova sequência, porém com o erro citado. Tabela 18: Caso de erro na transmissão. 0x46d0 0xf302 0xf3f8 0xf7f2 0x3d8a (0x2cf5) 0xc0a8 0x010b 0xc0a8 0x0101 0xf8f1 0xf300 O resultado da somatória de todos esses valores será 0x6ff88. Esse valor transformado em 16 bits, conforme algoritmo, será 0xff8e e seu complemento de 1 resultará em 0x0071, que é justamente a diferença, em hexadecimal, em relação ao valor correto e o erro ocorrido. Apesar dessa informação o receptor não poderá corrigir o erro, pois ele não tem a informação de em qual das words ocorreu o erro nos últimos dois bits. Assim, o receptor somente saberá que o pacote que chegou foi endereçado erroneamente à ele, já que não resultou em 0x0000, o que permite que o terminal ignore o conteúdo do datagrama recebido. 55

80 IP de Origem e Destino Os 32 bits seguintes ao checksum indicarão o endereço IP de origem e os próximos 32 bits o endereço IP do destino Opções e Padding Os últimos 32 bits são opcionais, e para cada aplicação esse campo poderá ter uma quantidade de alocação de bits. Porém, caso exista o campo opções, ele sempre será completado com zeros 2 para atingir 32 bits (TORRES, 2001). Entre as possibilidades de uso desses últimos bits existe a opção de realizar gravação da rota do datagrama e aplicações de segurança (INTERNET ENGINEERING TASK FORCE, 1981a) Fragmentação IP Conforme observado no descritivo do cabeçalho do datagrama IP, existem alguns campos relacionados a fragmentação. A existência dessa divisão fica clara ao analisar a relação entre as camadas de enlace, rede e transporte do modelo OSI, explicada anteriormente. O tamanho dos quadros do enlace poderão variar de acordo com a tecnologia empregada, que limita uma máxima quantidade de bits por quadro, chamada maximum transmission unit (MTU). Assim, o tamanho do datagrama IP pode ser estruturado para obter uma quantidade compatível de bytes ao MTU da camada de enlace. Porém, os dados poderão ser trafegados em tecnologias diferentes, com valores heterogêneos de MTU, que podem impedir que um datagrama IP completo seja disposto em um quadro (KUROSE; ROSS, 2011). O valor de 576 bytes é um valor interessante a ser utilizado, já que ele é compatível com todos os hosts (INTERNET ENGINEERING TASK FORCE, 1981a). Para resolver esse problema, foram adicionados alguns campos no cabeçalho IP para que a carga útil de um datagrama pudesse ser fragmentada em datagramas menores e coubessem em um quadro. Assim, os campos identificação, flags e offset de segmento têm como objetivo auxiliar na fragmentação e desfragmentação do datagrama IP. A camada que fará esse processo é a de rede (no modelo OSI), já entregando os dados não fragmentados para a camada de transporte (KUROSE; ROSS, 2011). 2 Torres (2001) explica que esses zeros adicionais também são conhecidos como pad ou padding 56

81 Como exemplo de uso dos campos no processo de fragmentação, pode-se considerar um datagrama com bytes para ser transmitido em um enlace com MTU igual a 1700 bytes. Os dados úteis do datagrama original serão 9980 bytes, considerando um cabeçalho com 20 bytes. Esse payload terá que ser dividido em um múltiplo de oito bytes, já que esta é a base para a contagem utilizada no offset do segmento. O menor número múltiplo de oito e menor do que o MTU será = Assim, os 9980 bytes serão fragmentados em blocos de 1696 bytes que resultará em 5 fragmentos completos e um fragmento com os restantes 1500 bytes 3. Portanto, serão no total 6 fragmentos em diferentes datagramas IP, que representam um original, que será remontado no destino, com auxílio de informações do cabeçalho. No campo identificação será inserido um valor que rotulará o datagrama a ser fragmentado e este valor estará presente também em todos seus fragmentos. A flag trará o bit 1 para indicar ao destinatário que existem outros fragmentos a chegar e o bit 0 indica o último fragmento. Outro campo do cabeçalho utilizado no processo de fragmentação e desfragmentação é o offset de segmento. Ele indicará a ordem de montagem dos fragmentos, para gerar um único datagrama. Neste campo atribui-se o valor 0 para indicar que os dados precisam ser inseridos a partir do byte 0. Assim, no exemplo dado, o segundo pacote conterá o valor 212 pois = 1696, o que indica que os dados do segundo pacote deverão ser inseridos a partir do byte de número 1696 (recorda-se que o primeiro byte é considerado como 0 ). Os dados do terceiro fragmento terão no campo offset de segmento o valor 424 que representa que os dados devem ser alocados a partir do byte 3392, ou seja, após o primeiro e segundo fragmento. Assim ocorrerá sucessivamente até o último fragmento (KUROSE; ROSS, 2011) Exemplo de aplicação IP no DASH No caso do DASH os conteúdos de áudio e vídeo não são encapsulados diretamente no payload do datagrama IP. Com o DASH, as solicitações dos recursos estarão no protocolo HTTP, dentro dos pacotes TCP. Já para a transferência dos pedaços dos vídeos, o conteúdo estará diretamente dentro dos pacotes TCP. Aplicando-se o exemplo para o DASH, esses pacotes TCP estarão dentro do payload representado pela figura 25. Com a (5 1696) =

82 evolução para as próximas seções o conteúdo de dentro de cada payload será desmembrado e discutido, para a aplicação DASH. Cabeçalho IP (20 Bytes) Payload IP (até Bytes) Figura 25: Estrutura do datagrama IP. Fonte: Adaptado de Torres (2001, p. 81). 4.3 CAMADA DE TRANSPORTE: UDP e TCP Conforme abordou-se na sessão anterior, o DASH não trabalha com a inserção do conteúdo de áudio e vídeo diretamente dentro do payload IP, somente com o acréscimo do cabeçalho IP. Esse fato traz uma vantagem pois o IP não garante por si só que os datagramas cheguem ao destino, pois essa garantia é de responsabilidade da camada de transporte, que é explicada nesta sessão. Na realidade, os dados multimídia primeiramente passarão pelo tratamento da camada de transporte, com a adição do cabeçalho UDP ou TCP, para depois serem enviados para o encapsulamento IP pela razão supracitada. Conforme explicado ao descrever modelo TCP/IP, existem dois principais protocolos para transportar e garantir a integridade dos dados: o TCP e o UDP. Uma das funções desses protocolos é gerenciar as portas, que são complementos dos endereços IP e indicam uma aplicação específica para qual os dados devem ser enviados. Existem portas, que são indicadas no cabeçalho do pacote de transporte (BARRETT; KING, 2010). Podese estabelecer uma analogia entre as portas e o número de uma casa em uma vila. O endereço IP seria como a cidade, rua, número e bairro do condomínio; porém, dentro dele existem diversos moradores (aplicações), cada um com um número de casa (porta). Essa camada também fará o processo de multiplexação e demultiplexação dos dados. Isso porque diversas aplicações podem enviar dados para um único destino e a camada de transporte irá rotular os segmentos, entre outras informações, com a porta da aplicação destinatária e esses serão unidos no datagrama IP (encapsulamento da camada de rede), o que caracteriza o processo de multiplexação. No destino, os diversos pacotes IP terão seus dados transferidos para a camada de transporte, que irá demultiplexar os dados, pois enviará para a aplicação correta cada informação, ao analisar as portas de destino 58

83 (KUROSE; ROSS, 2011). As diferenças entre a multiplexação TCP e a UDP, assim como cada estrutura de seus segmentos, serão explicados a seguir UDP Este protocolo é caracterizado por não ser orientado à conexão, já que não estabelece uma sessão que se abre no início da comunicação entre dois terminais e se finaliza com a transmissão da última mensagem. Esse processo pode ser compreendido com a análise da multiplexação e demultiplexação dos segmentos UDP. No cabeçalho desse protocolo haverá um endereço de porta de destino e da fonte para cada segmento. Em cada aplicação pode-se relacionar um número de porta a um socket 4. Quando esse pacote é recebido, o terminal destinatário irá, na camada de transporte, analisar a porta de destino do segmento e verificar o socket associado à ela, que é atrelado a alguma aplicação. Vale ressaltar que cada terminal terá diversas aplicações em atividade e a cada uma delas será associado uma porta para cada um de seus sockets. Isso permite que a camada de transporte faça a demultiplexação dos dados recebidos pela camada de rede, com base no número da porta, que levará a um socket específico de uma aplicação (KUROSE; ROSS, 2011). Portanto, esse processo trata individualmente cada novo segmento, associando-o a um socket pré estabelecido pela aplicação. Algumas das vantagens em utilizar o UDP se dão pelo fato de que ele, por não ser orientado à conexão, não necessita uma troca inicial de mensagens entre origem e destino para abrir uma conexão. O protocolo UDP também não utiliza mecanismos de controle de tráfego, recebimento e retransmissões de pacotes perdidos. Essas características citadas provém ao UDP a propriedade de ter baixo atraso na transmissão, já que não tomará tempo em retransmissões, abertura de conexões e controles de tráfego. Essa propriedade também é reforçada devido à estrutura do protocolo, que é simples, o que exige menor processamento computacional para realizá-la, acarretando em menor tempo de processamento e possibilidade de gerenciar um número de conexões. Esses fatores se tornam interessantes quando se pensa em distribuição de conteúdos multimídia, que são robustos a pequenas perdas de pacotes, porém sensíveis ao atraso. Porém, o TCP tem sido uti- 4 Kurose e Ross (2011) definem socket como uma interface de software, que recebe e envia mensagens entre a rede e a aplicação. O socket é o conector de saída e entrada de informações da aplicação com todo o processo de transmissão de suas informações por uma rede. 59

84 lizado também para transmissão multimídia, devido à redução da perda de pacotes em redes e também bloqueio de firewalls para pacotes UDP (KUROSE; ROSS, 2011). A RFC 768 da Internet Engineering Task Force (1980) trata da estrutura do segmento UDP e diz que ele foi desenvolvido para ser um protocolo simples e que aplicações que exijam confiabilidade de entrega usem o TCP, que será explicado no próximo tópico. A estrutura tem apenas quatro campos, explicados de acordo com a RFC 768 e atribuídos aos bits do cabeçalho conforme a figura 26 (INTERNET ENGINEERING TASK FORCE, 1980). Figura 26: Distribuição dos bits do cabeçalho do segmento UDP. Fonte: Adaptado de Internet Engineering Task Force (1980, p. 2) Porta de origem e destino Cada campo de indicação de porta é composto por dois bytes (16 bits) e informam qual é o número da porta associada ao socket de origem e destino, respectivamente. Caso não seja exista um número de porta, é atribuído o valor zero Tamanho total Esse campo é composto por um byte. Traz a quantidade de bytes do segmento, contando com o cabeçalho e dados úteis. O mínimo valor é oito: dois bytes para cada porta, um para tamanho total e outro para checksum Checksum É composto pelo último byte do cabeçalho e tem seu algoritmo igual ao apresentado no cabeçalho IP. A diferença é que ele considera para a somatória do pseudocabeçalho IP, o cabeçalho UDP e dados úteis. Esse pseudocabeçalho, anexado antes do segmento UDP, conterá os IPs da origem, destino, protocolo utilizado e o tamanho do cabeçalho UDP. A vantagem do uso dos IPs no checksum é que a entrega do segmento para um 60

85 IP errado será detectada (STALLINGS, 2005). Vale frisar que essa característica de detecção já foi exemplificada na apresentação do cabeçalho IP dessa dissertação. Naquele exemplo utilizou-se como IP de origem o (0xc0a8 0x010b) e de destino o (0xc0a8 0x0172). No mesmo exemplo também foi demonstrada a detecção do erro, ao alterar os dois últimos bits do IP de destino. Ressalta-se que caso os dados não estejam em um múltiplo de oito bits, devem ser acrescentados zeros para satisfazer essa condição, para que o último grupo da somatória tenha 16 bits. Caso o segmento chegue no destino com o checksum preenchido de zeros, quer dizer que a origem não quis gerar esse algoritmo de verificação de erros TCP Diferente do UDP, esse protocolo é orientado à conexão. Essa característica também está ligada ao processo de multiplexação e demultiplexação dos dados entre a camada de rede e transporte. Ao se orientar a conexão, o TCP irá se diferenciar do processo do UDP pois o socket TCP é criado com a base de quatro elementos: IP da fonte, número da porta da fonte, IP do destino e número da porta do destino (KUROSE; ROSS, 2011). Assim é estabelecida uma conexão entre sockets únicos, gerados pelos dados de ambas as pontas. Ao receber os dados da camada de rede o destinatário analisará, na camada de transporte, esses quatro elementos, para assim enviar as informações para a aplicação correta. Outra diferença entre o UDP e TCP é que, para o processo não orientado à conexão, dados procedentes de IPs diferentes, mas com a mesma porta de destino, irão para o mesmo socket. Porém, para o TCP é criado um socket para cada par de IP remetente e porta de destino. A única exceção é para o momento de abertura de uma conexão, pois o TCP espera, por exemplo na porta 6789, alguma requisição de começo de conexão, independente do IP de origem. Para a abertura de uma conexão, o terminal enviará um pedido de início de conexão para uma porta preestabelecida. O terminal remetente receberá o pedido e verificará qual aplicação deseja abrir uma conexão, e com base nos quatro elementos (IP e porta fonte, IP e porta destino) irá criar um socket específico para que todos os dados que chegarem com as quatro informações serão destinados para a mesma aplicação, ou seja, está aberta uma conexão entre duas aplicações de dois terminais diferentes (KUROSE; ROSS, 2011). 61

86 O TCP também tem ferramentas de controle de congestionamento de tráfego de rede, que possibilitam o envio de quantidade de dados de acordo com a capacidade de leitura do cliente, assim como características da rede. O protocolo em questão também consegue organizar a ordem dos pacotes recebidos e requisitar somente os perdidos. Outra tarefa do TCP é receber o fluxo de dados da camada de rede e dividí-lo em pedaços de 1460 bytes para compatibilizar com o tamanho do quadro ethernet (1500 bytes), já que serão adicionados os cabeçalhos TCP (20 bytes) e IP (20 bytes) (TANENBAUM; WETHE- RALL, 2010). O cabeçalho TCP, assim como a função de cada campo, são definidos pela RFC 793 da Internet Engineering Task Force (1981b) e apresentados a seguir. A estrutura desse cabeçalho é representada pela figura 27, em que os bits destacados em cor mais escura representam o campo reservado, originalmente com oito bits. Porém, com o tempo, utilizaram-se dois bits para flags, explicadas posteriormente. Um exemplo de um cabeçalho com dados numéricos também será apresentado futuramente. Figura 27: Distribuição dos bits do cabeçalho do segmento TCP. Fonte: Adaptado de Tanenbaum e Wetherall (2010, p. 350) Porta de origem e destino No primeiro e segundo campos, compostos por dois bytes cada, são mostrados os números da porta de origem e destino, respectivamente, da mesma forma apresentada no cabeçalho UDP (INTERNET ENGINEERING TASK FORCE, 1981b). 62

87 Número de sequência Esse campo, com 32 bits, traz o número da etiqueta do primeiro byte dos dados. Essa etiqueta rotula linearmente cada byte do fluxo de dados, iniciando com um valor aleatório, combinado entre a origem e o destino (KUROSE; ROSS, 2011). Um exemplo seria a transmissão de um dos trechos de vídeo em DASH, que resultou em uma quantidade de dados composta por bytes, que serão divididos em 1460 bytes por cada segmento TCP, o que resulta em 21 segmentos necessários para transmitir o trecho do vídeo por completo. Toma-se como valor combinado de etiqueta inicial o número 48. Assim, o primeiro byte será rotulado com esse número, acrescendo uma unidade a cada byte até o último, que terá a etiqueta de número Após cada byte de dados devidamente rotulado é possível enviar no campo número de sequência o valor da etiqueta do primeiro byte dos dados. No exemplo, o valor será 48 no primeiro segmento, 1508 no segundo segmento, 2968 no terceiro segmento, e assim consecutivamente até o último segmento, conforme representa a figura 28. Figura 28: Número de sequência do TCP. Fonte: Adaptado de Kurose e Ross (2011, p. 178). O número de sequência é utilizado para controle da reconstrução dos dados no destinatário, pois os dados podem ser organizados na forma correta, já que existe um rótulo linear de cada byte do arquivo completo. Por esse motivo, a falta de pedaços do arquivo também será facilmente notada, com base no número de sequência que será validado no pelo número de confirmação, conforme explicado no próximo tópico Número de confirmação O número de confirmação está relacionado ao procedimento de etiquetagem explicado na elaboração do número de sequência. Isso porque esse campo, que ocupa 32 bits, traz 63

88 o número do rótulo do próximo byte esperado, com base no que já foi recebido. Esse número só será mudado ao se verificar que os bytes já recebidos podem ser organizados sequencialmente sem trechos faltantes (KUROSE; ROSS, 2011). No exemplo da figura 28, após receber o primeiro segmento, o destinatário responderá ao remetente com o valor 1508 no campo do número de confirmação; ou seja, o próximo segmento esperado é ter os dados a partir desse valor, pois já recebeu os bytes rotulados de 48 a 1507 e espera continuar o recebimento dos próximos dados da sequência. Pode acontecer que, após a transmissão de vários segmentos subsequentes, não haja mudança no número de confirmação. Isso indica que o segmento com o número de sequência 1508 não teve confirmação de chegada por parte do cliente, ou seja, pode ter sido corrompido ou perdido na transmissão. Assim, o servidor, ciente do problema, retransmitirá o segmento após o timeout Comprimento do cabeçalho Traz a quantidade de grupos de 32 bits no cabeçalho TCP, representada em um código de quatro bits (INTERNET ENGINEERING TASK FORCE, 1981b) Flags O cabeçalho tem oito flags, compostas por um bit cada, que indicam estado ativado quando o bit está em um e desativado quando o bit está em zero. Eles são explicados, um a um, na sequência. CWR Esta flag é chamada Congestion Window Reduced e, se ativada, sinaliza que o transmissor reduziu o tamanho da janela, que será explicada em breve. Essa ação leva a uma diminuição da quantidade de arquivos transmitidos sem a chegada de uma confirmação de recebimento do dado, chamado recibo (Acknowledgment) (TANENBAUM; WETHERALL, 2010). ECE É uma sigla para explicit congestion notification (ECN) echo. Essa flag juntamente com a CWR é responsável por sinalizar um congestionamento (ECN). O receptor envia ECN-echo para o transmissor como pedido de redução na transmissão, ou seja, realize 5 Tempo que começa a ser contado a partir do envio do segmento, zerado com a confirmação da chegada dele no cliente. Caso ultrapassado valor estipulado, o segmento será retransmitido. 64

89 uma redução no tamanho da janela. O receptor deixará de informar ECE quando o transmissor devolver CWR (TANENBAUM; WETHERALL, 2010). URG Esta flag ativa a verificação do ponteiro de urgência, que indicará que os próximos bytes serão urgentes. Em breve será explicada mais detalhadamente essa situação. ACK A flag Acknowledgment é utilizada para indicar que o número de confirmação é válido. Ou seja, espera-se novos dados (indicados no número de confirmação), o que confirma que os anteriores foram recebidos (INTERNET ENGINEERING TASK FORCE, 1981b). Essa flag é o recibo de recebimento de pacotes e caso o bit seja zero quer dizer que o segmento não traz confirmações. PSH Esta flag é chamada de PUSH que solicita ao receptor que todas as informações com essa flag ativada sejam entregue imediatamente à aplicação destinatária, sem que se realize um buffer dessa informação (TANENBAUM; WETHERALL, 2010). RST Indica RESET, isto é, reinício da sessão. Essa flag será ativada caso ocorra algum erro ou também para recusar uma conexão (TANENBAUM; WETHERALL, 2010). SYN Sigla para Synchronize sequence numbers, para que seja acordado o número de sequência inicial de uma sessão. Portanto responsável por iniciar uma conexão, processo explicado em breve (INTERNET ENGINEERING TASK FORCE, 1981b). FIN Flag indicadora de que não há mais dados para serem enviados, assim encerrando uma conexão, que também terá seu processo explicado oportunamente Tamanho da janela Este campo ocupa 16 bits do cabeçalho e define quantos bytes terá o tamanho da janela. O janelamento TCP é uma técnica utilizada para permitir o envio de novos dados, mesmo sem ter recebido a confirmação da entrega dos anteriores. Essa possibilidade causa um melhor aproveitamento do tempo, já que o sistema não esperará a confirmação da chegada de cada pacote para enviar um novo, e sim aproveitará esse tempo enviando mais dados enquanto espera. Porém, deve haver um limite para envio de novos dados sem receber as confirmação dos anteriores. Essa demarcação é definida pelo tamanho da 65

90 janela, nesse campo de dois bytes. No caso do TCP a janela tem tamanho variável, avança de acordo com o recebimento das confirmações e trabalha byte a byte, ao invés de a cada pacote (TORRES, 2001). A figura 29 demonstra como se dá essa dinâmica. t Janela (tamanho fixo) t +1 Aguardando ACK Próximos envios Ponteiro 1 Ponteiro 2 Ponteiro 3 ACK t +2 Ponteiro 1 Ponteiro 2 Ponteiro 3 ACK ACKACK Bytes Bytes Bytes Ponteiro 1 Ponteiro 2 Ponteiro 3 Figura 29: Dinâmica da janela do TCP. Fonte: Adaptado de Torres (2001, p. 107). Na figura 29 é possível observar um fluxo de bytes que foram numerados em sequência. No caso apresentado, foi utilizada uma janela fixa para facilitar a compreensão da dinâmica do algoritmo. O ponteiro 1 aponta entre o último byte que houve confirmação (ACK) e o que ainda não teve tal validação. O ponteiro 2 divide os bytes já enviados e os próximos a serem transmitidos. Ressalta-se que este ponteiro se desloca em uma velocidade constante, no caso apresentado, dois bytes por unidade de tempo. Por fim, o último ponteiro aponta o último byte da janela. Os ponteiros 1 e 3 se moverão quando ocorrer o recebimento de confirmação de recebimento dos bytes anteriores à janela, enquanto o ponteiro 2 se move constantemente, conforme ilustrado nos tempos t + 1 e t + 2. Caso o ponteiro 2 chegue ao final da janela, o envio será pausado. Na prática, o tamanho dessa janela é variável, conforme informação da escala da janela, presente em opções e explicado no tópico dedicado a esse campo. Ao inserir o valor zero neste campo, o cliente diz ao servidor que já recebeu todos os pacotes até o número de confirmação 1 e necessita de uma pausa na transmissão. A retomada pode ser feita ao enviar um segmento com o número 66

91 de confirmação corrente e o campo tamanho da janela com um valor diferente de zero (TANENBAUM; WETHERALL, 2010) Checksum Este campo de dois bytes trará o mesmo algoritmo apresentado no UDP conforme a estabelece a RFC 768 (INTERNET ENGINEERING TASK FORCE, 1980) Ponteiro de urgência Este campo, com 4 bytes, aponta a quantidade de bytes com caráter de urgência, contado a partir do número de sequência vigente. Dessa forma nenhum processo deve ser interrompido até que todos os bytes de urgência tenham chegado ao destinatário. Essa função somente será ativada com o bit da flag URG setado no número um (TANENBAUM; WETHERALL, 2010) Opções Este campo pode ocupar até 40 bytes e sua quantidade deve ser múltipla de oito bits. Ele foi criado para adicionar funcionalidades no cabeçalho TCP. Neste campo haverá uma sequência de oito bits zero para indicar seu fim. Entre cada recurso dentro do campo opções haverá uma sequência de sete zeros e por último o bit um. Dentre as funcionalidades possíveis, está o tamanho máximo de segmento e será enviado juntamente com o bit SYN igual a um, ou seja, na abertura da sessão (INTERNET ENGINEERING TASK FORCE, 1981b). Outra função está ligada à variação do tamanho da janela TCP. Com o window scale o tamanho da janela poderá ser maior, já que com os 16 bits do campo é possível chegar no máximo a uma janela de 64 KB. Essa função permite deslocar o valor do tamanho da janela 14 bits para a esquerda o que resulta em janelas de até = 30 bits, ou seja, por volta de 1 GB de janela (TANENBAUM; WETHERALL, 2010) Processo de abertura de conexão Para abertura de uma conexão, o cliente pode enviar ao servidor um número de sequência escolhido e o pedido de SYN, o que pede uma sincronização desse número com a outra ponta da futura conexão. O servidor irá responder com esse número de sequência 67

92 juntamente com o SYN e ACK ativados. Por fim, o cliente retornará um ACK para o servidor com uma solicitação, o que inicia a conexão entre as duas pontas. Esse processo é conhecido por three-way handshake, pois firma um acordo de conexão em três passos e é representado pela figura 30 (TORRES, 2001). Cliente Servidor Número de Sequência + SYN Número de Sequência + SYN + ACK Solicitação + ACK Tempo Figura 30: Abertura da conexão TCP. A figura 31 traz um exemplo, com um cenário do DASH, do terceiro passo da abertura de conexão, na qual o reprodutor do vídeo DASH, com IP , responde ao servidor do conteúdo (IP ), com a flag ACK ativada (igual ao bit 1). No cabeçalho também pode-se inferir que o cliente já recebeu todos os bytes anteriores corretamente, já que o campo de número de confirmação autentica o recebimento dos bytes até a sequência 1507 e o primeiro byte do datagrama em questão traz o número de sequência seguinte, O exemplo também esclarece o uso do campo do comprimento do cabeçalho, que traz o número 5, que é a quantidade de grupos de 32 bits no cabeçalho enviado. No caso do campo do tamanho da janela o valor 0, pausará a transmissão temporariamente. Tal campo zerado indica que apesar de todos os bytes até a sequência 1507 tenham sido recebidos, o cliente não deseja novos datagramas. Esse cenário pode acontecer no caso do cliente não ter conseguido tomar todas as providências com os dados, como, por exemplo, a situação do reprodutor DASH estar com o buffer cheio. O estudo desse caso será abordado nos testes realizados. O campo seguinte traz o checksum do cabeçalho, com o algoritmo já apresentado anteriormente, e, por fim, o campo de ponteiro de urgência 68

93 aparece com o valor 0 pois não está sendo utilizado. Figura 31: Exemplo de distribuição dos bits do cabeçalho do segmento TCP. Fonte: Adaptado de Tanenbaum e Wetherall (2010, p. 350) Processo de fechamento de conexão Para fechamento da conexão estabelecida, uma das partes informa que não existe mais dados a serem transmitidos, ao setar a flag FIN. No processo ocorrerá essa finalização por ambas as partes, da seguinte forma: um terminal A envia o pedido de finalização da conexão (mensagem com FIN ativado), o terminal B responde um ACK, com o FIN inativo, o que confirma o entendimento do pedido de finalização da conexão. Depois, o terminal B envia o pedido de finalização, com o FIN ativado, e o terminal A retorna um ACK, conforme figura 32 (TORRES, 2001) Exemplo de aplicação TCP no DASH No caso do DASH o protocolo de transporte utilizado é o TCP. Assim, quando é solicitado o início da reprodução no Mini-PC Android, o primeiro passo a ser feito é estabelecer uma conexão TCP, realizada conforme já explicado. Da mesma forma, quando o vídeo é finalizado existirá uma solicitação, por parte da caixa Android, para encerramento da conexão. Depois desse estabelecimento a aplicação VLC enviará uma mensagem HTTP solicitando o recurso para o servidor. Esta mensagem, assim como os pedaços do vídeo, codificados em H.264 e inseridos em um container mp4, estarão dentro do payload TCP, conforme a figura

94 Terminal A Terminal B FIN ACK FIN ACK Tempo Figura 32: Fechamento da conexão TCP. Cabeçalho IP (20 Bytes) Payload IP (1480 Bytes) Cabeçalho TCP (20 Bytes) Payload TCP 1460 Bytes Figura 33: Estrutura pacote TCP/IP. 4.4 CAMADA DE APLICAÇÃO: HTTP, RTP/RTCP e RTSP Nessa camada estarão as aplicações que tratarão os dados de forma mais próxima ao usuário. Os processos de estruturação e codificação DASH, já apresentados no terceiro capítulo estão nessas camadas, em aplicativos dedicados à essas tarefas. Na cadeia de transmissão de dados em redes IP, voltadas ao streaming, existem protocolos que fazem a administração das informações, repassando-as para a camada de transporte. Entre eles, são destacados em sessões dedicadas, o HTTP, RTP, RTCP e o RTSP HTTP O HTTP é o protocolo utilizado na Internet que padroniza a comunicação entre um servidor e um cliente, e é normatizado pela RFC 2616 da Internet Engineering Task Force (1999). O HTTP é aplicado sobre a camada de transporte TCP, com o uso de um socket, 70

95 que utiliza a rede IP. Entre as possíveis trocas de mensagens entre servidor e cliente está a solicitação de conteúdos, localizados pelo Uniform Resource Locator (URL) 6. O HTTP é rotulado como um protocolo sem estado, pois nativamente ele trata cada solicitação de recurso de forma separada, sem levar em consideração os pedidos realizados anteriormente, ao conectar e desconectar conexões TCP entre o servidor e o cliente a cada troca de informação. Esse processo, sem persistência, implica em haver múltiplos three-way handshakes para abertura de cada conexão, o que dispende tempo e recursos computacionais. Porém, a partir da versão HTTP 1.1 surge a possibilidade de criar conexões TCP persistentes, que agrupam diversas solicitações e respostas em uma única conexão (BARRETT; KING, 2010). Nessa configuração, após a resposta do servidor (no segundo passo da abertura), será mantida aberta a conexão para que sejam trocadas solicitações e reconhecimentos (ACK) entre cliente e servidor sem a solicitação de finalização. O fim só será requisitado caso o tempo de recebimento entre cada solicitação ultrapasse um valor estipulado na conexão, que pode indicar fim das requisições (KUROSE; ROSS, 2011). Como exemplo prático de conexão não persistente é possível considerar que em um servidor existe um filme que foi particionado em vários pedaços com dois segundos cada, conforme aplica-se no DASH. No reprodutor serão feitas requisições HTTP de cada trecho de dois segundos, uma de cada vez. O pedido do recurso implicará no seguinte processo: abertura de uma conexão TCP, com o three-way handshake, transferência de todos os pacotes do arquivo pedido e, por fim, o fechamento da conexão, conforme já explicado anteriormente. Para o próximo trecho do vídeo ser carregado no reprodutor é preciso que novamente seja feito todo o processo, com a abertura da conexão, transferência de todo o arquivo seguinte, e fechamento da conexão. A figura 34 ilustra esse processo. Um outro tipo de conexão é a persistente, que pode ser com requests sequenciais ou em pipeline. No caso das solicitações em sequência para se transferir os trechos do vídeo haverá somente uma abertura de conexão TCP. Isso porque após a transferência completa de todos os pacotes do primeiro pedaço do vídeo não haverá o fechamento da conexão e, na sequência, um novo trecho será solicitado, o que já dará início a transferência dos 6 URLs são endereços utilizados para localizar recursos em uma rede, e para o HTTP ele é padronizado, na RFC 2396, na seguinte forma: http URL = http: // servidor [ : porta ] [caminho do recurso [? pergunta da aplicação]] (INTERNET ENGINEERING TASK FORCE, 1998b). 71

96 Cliente { Abertura Conexão Transferência Trecho 1 { Fechamento{ Conexão { Abertura Conexão Transferência Trecho 2 { Seq + SYN+ACK ACK FIN Seq + SYN+ACK Seq + SYN FIN ACK Seq + SYN Figura 34: Conexão não persistente. Servidor Solicitação + ACK Solicitação + ACK Tempo Fonte: Adaptado de Tanenbaum e Wetherall (2010, p. 685). pacotes, sem abertura de nova conexão. Esse processo ocorrerá sucessivamente para todos os trechos do vídeo, conforme ilustra a figura 35. Cliente { Abertura Conexão Transferência Trecho 1 { Transferência Trecho 2 { Transferência Trecho 3 { Tempo Seq + SYN+ACK Seq + SYN Servidor Solicitação + ACK Solicitação + ACK Solicitação + ACK Figura 35: Conexão persistente com solicitações sequenciais. Fonte: Adaptado de Tanenbaum e Wetherall (2010, p. 685). Outra possibilidade de conexão persistente é realizar os requests em pipeline, ou seja, pedir em paralelo os trechos do vídeo, não esperando terminar a transferência de um para começar o outro. A figura 36 ilustra o exemplo da conexão em pipeline. 72

97 Cliente { Abertura Conexão Transferência Trecho 1 { Transferência Trecho 2 { Transferência Trecho 3 { Transferência Trecho 4 { Seq + SYN+ACK Seq + SYN Servidor Solicitação + ACK Solicitação + ACK Solicitação + ACK Solicitação + ACK Tempo Figura 36: Conexão persistente com solicitações em pipeline. Fonte: Adaptado de Tanenbaum e Wetherall (2010, p. 685). Portanto, a dinâmica da comunicação HTTP se dá com requisições, que são solicitações e ações que o cliente pede para o servidor, e respostas, que são as consequências de cada requisição. Ambas etapas são explicadas nas próximas sessões Estrutura da requisição O pacote de requisição HTTP é estruturado em três partes. A primeira é a linha de requisição, dividida em nome do método, endereço URL relacionado à requisição e indicação da versão do protocolo, por exemplo: GET /diretorio/imagens HTTP/1.1. A segunda parte contém os cabeçalhos, que trazem campos de informações também associados à requisição e têm a estrutura de nome do campo:valor do campo, como exemplo: Host: (que mostra o endereço do servidor) ou Connection: close (indica que a sessão deve ser fechada após requisição). A última parte do pacote HTTP é o corpo da entidade, que pode existir no caso de envio de dados ligados à requisição (KUROSE; ROSS, 2011). Um exemplo de uma mensagem de requisição, pelo Mini-PC Android ( ), do pedaço da sequência ZP1, durante a reprodução DASH, conforme tabela 19. Existem diversos tipos de requisições, relacionados ao método utilizado, alguns são mostrados na tabela

98 Tabela 19: Mensagem requisição do Mini-PC Android. GET /Arquivos DASH/PosBanca/zp1 t1/zp1 t1 1438kbit/zp1 t12.m4s HTTP/1.1 Host: Tabela 20: Alguns tipos de métodos de requisições HTTP. Método Ação relacionada GET Requisita um objeto na URL indicada HEAD Semelhante ao GET, porém a resposta não vem com o objeto requisitado PUT Escreve os dados da entidade na URL indicada POST Anexa os dados da entidade em subordinação à URL indicada DELETE Apaga os dados da URL referenciada Fonte: Adaptado de Internet Engineering Task Force (1999) Estrutura da resposta O servidor, após receber uma requisição, irá enviar uma resposta de acordo com o método explicado na sessão anterior. A estrutura da resposta HTTP é idêntica à requisição, só alterando-se a primeira parte, de linha de requisição para a linha de estado. Essa estrutura-se em versão do protocolo, código de estado e o significado do código, conforme o exemplo: HTTP/ Accepted. Da mesma forma que existem diversos tipos de métodos na requisição encontram-se vários códigos de estados de respostas, compostos por três dígitos, na qual o primeiro indica a classe da resposta. Essa pode ser de informação (código 1xx), sucesso (código 2xx), redirecionamento (código 3xx), erro de cliente (código 4xx) e erro de servidor (código 5xx). Nos cabeçalhos podem ser descritos qual o servidor utilizado, data de envio do pacote, data da última modificação, tamanho do payload em bytes, e tipo de conteúdo (INTERNET ENGINEERING TASK FORCE, 1999). A tabela 21 traz o exemplo para a resposta do reprodutor DASH, acusando o recebimento completo do arquivo solicitado no exemplo anterior. Tabela 21: Resposta HTTP do reprodutor DASH. HTTP/ OK Date: Thu, 28 Nov :20:01 GMT Last-Modified: Wed, 27 Nov :58:15 GMT Content-Length: Na linha de estado existe o código de estado, alguns mais típicos são descritos na tabela

99 Tabela 22: Alguns códigos de estados em respostas HTTP. Código Significado 1xx: Indica uma mensagem apenas informativa 2xx: Indica sucesso de algum tipo 200 OK 201 Created (Criada) 202 Accepted (Aceita) 3xx: Redireciona o cliente para outra URL 301 Moved Permanently (Mudou permanentemente) 302 Moved Temporarily (Mudou temporariamente) 304 Not Modified (Não modificada) 4xx: Indica um erro na parte do cliente 400 Bad request (Requisição malformada) 401 Unauthorized (Não autorizado) 403 Forbidden (Proibido) 5xx: Indica um erro na parte do servidor 500 Internal Server Error (Erro interno do servidor) 502 Bad Gateway (Gateway errado) 503 Service Unavailable (Serviço indisponível) Fonte: Adaptado de Barrett e King (2010) Sintaxe das mensagens HTTP A sintaxe das mensagens HTTP é baseada em duas RFCs. Uma delas é a RFC 822 da Internet Engineering Task Force (1982), que especificou como seriam os cabeçalhos das trocas de mensagens entre dois elementos e padronizou como código o American Standard Code for Information Interchange (ASCII). A outra referência é a RFC 2045 da Internet Engineering Task Force (1996) e trata-se de um complemento da primeira. Chamada de Multipurpose Internet Mail Extensions (MIME), a RFC 2045 e suas partes permitiram que elementos como figuras, vídeo e áudio, não presentes no código ASCII, pudessem ser compatibilizados na troca de mensagens pela Internet. Para tal são adicionados cabeçalhos do MIME ao cabeçalho da Internet Mail (RFC 822), que dão informações sobre o código binário dos dados úteis do corpo da mensagem. Essas referências rotulam o payload com o seu tipo de codificação e tamanho em bytes, para que o destinatário possa compreender como decodificar esses dados binários. Já os cabeçalhos da Internet Mail e MIME são textos codificados em ASCII, conforme suas respectivas RFCs. Assim, ao tomar o exemplo do código apresentado na sessão da estrutura da resposta pode-se afirmar que esse código será direcionado para a camada de transporte conforme a tabela ASCII, que gera um 75

100 fluxo de bits. Após o fluxo da linha de estado e dos cabeçalhos virá o código binário do arquivo de vídeo, codificado no padrão MPEG. Dessa forma, o cliente que receber esse pacote saberá separar a linha, cabeçalhos e dados úteis pois eles estão padronizados, e também saberá encaminhar o vídeo para a aplicação que consiga realizar a decodificação. O formato das mensagens segue conforme demonstrado nas figuras 37 e 38, para uma mensagem de requisição e de resposta, respectivamente. Linha de requisição Linhas de cabeçalho Linha em branco Corpo da entidade { { { { Método SP URL SP Versão CR LF Nome do campo de cabeçalho SP Valor CR LF... Nome do campo de cabeçalho SP Valor CR LF CR LF Legenda: SP = Espaço CR = Carriage Return LF = Line Feed Figura 37: Formato da mensagem de requisição HTTP. Fonte: Adaptado de Kurose e Ross (2011, p. 77). Nas figuras 37 e 38 o código SP identifica espaço, CR quer dizer carriage return que significa que o ponteiro de leitura deve voltar ao início e o LF é de line feed, que solicita a mudança para a próxima linha. Assim CR juntamente com LF faz o ponteiro de leitura ir para o início da próxima linha. A RFC 2616 deixa claro que sua sintaxe de mensagens não é totalmente compatível com o MIME, se diferenciando por alguns aspectos. Entre eles está que o campo do cabeçalho MIME-Version é opcional para o HTTP, e caso ele exista indicará que o cabeçalho HTTP está somente com os campos totalmente compatíveis com a estrutura MIME. Também a estrutura do formato das datas é diferente para o HTTP. Outros pontos de diferença se relacionam com os campos do MIME e do HTTP, que por vezes existem 76

101 Linha de estado Linhas de cabeçalho Linha em branco Corpo da entidade { { { { Versão SP Código de Estado SP Frase CR LF Nome do campo de cabeçalho SP Valor CR LF... Nome do campo de cabeçalho SP Valor CR LF CR LF Legenda: SP = Espaço CR = Carriage Return LF = Line Feed Figura 38: Formato da mensagem de resposta HTTP. Fonte: Adaptado de Kurose e Ross (2011, p. 78). em um formato e não no outro, principalmente os que envolvem codificação. Isso ocorre, por exemplo, no campo Content-Transfer-Encoding do MIME, que não existe no HTTP, o que exige que equipamentos de rede que fazem a conversão entre MIME e HTTP retirem esse campo (INTERNET ENGINEERING TASK FORCE, 1999) RTP e RTCP Esse protocolo de transporte em tempo real, chamado real-time transport protocol (RTP) normalmente utiliza o protocolo UDP para transporte de seu conteúdo. O RTP propriamente é utilizado para carregar dados com característica de tempo real, como áudio e vídeo. Juntamente com o RTP é utilizado um outro protocolo, chamado RTP control protocol (RTCP), que conferirá características de controle ao RTP. O RTCP não carrega dados de áudio e vídeo e sim dados para controlar a qualidade do serviço e informações sobre os participantes da sessão. Porém ambos não garantem a entrega do pacote ou que eles cheguem em ordem (INTERNET ENGINEERING TASK FORCE, 2003a). 77

102 RTP A principal função do RTP é multiplexar diferentes fluxos de áudio, vídeo e texto, em um único fluxo para o UDP. Para a demultiplexação são adicionados dados que identificam cada fluxo e para reprodução síncrona deles existe a adição de marcas de tempo (TANENBAUM; WETHERALL, 2010). Por exemplo, para transmissão de um conteúdo de áudio a 96 kbps o RTP pode coletar esse fluxo em grupos de 40 milissegundos. Assim, cada grupo será composto por , 04 = 3840 bits, ou seja, 480 bytes. Esses 480 bytes terão um cabeçalho RTP anexado para ser disponibilizado em um socket para o UDP. O cabeçalho RTP demonstra com mais detalhes essas e outras características para transmissão de áudio e vídeo. A RFC 3550 da Internet Engineering Task Force (2003a) padroniza o RTP e com base nela apresenta-se o cabeçalho RTP. Ele tem obrigatoriamente os 12 primeiros bytes em todos os pacotes, e os seguintes dependerão do número de fontes que contribuem no fluxo, tornando assim o tamanho do cabeçalho variável. A distribuição dos bits é representada na figura 39. Figura 39: Distribuição dos bits do cabeçalho RTP. Fonte: Adaptado de Internet Engineering Task Force (2003a, p. 13). Versão (V) Esse campo, composto de dois bits, indica a versão do RTP utilizada. A RFC 3550 apresenta a versão número 2. Padding (P) Caso o campo, de um bit, esteja ativado quer dizer que foi realizado padding na parte dos dados, para que completasse um múltiplo de quatro bytes. O último byte dos dados indica quantos bytes de padding foram adicionados. 78