SOCIEDADE EDUCACIONAL DE SANTA CATARINA - SOCIESC INSTITUTO SUPERIOR TUPY - IST

Jefferson Rafael Kozerski DISTRIBUIÇÃO DE VÍDEO UTILIZANDO HTTP LIVE STREAMING

Joinville 2011/2

J EFFERSON R AFAEL KOZERSKI

Distribuição De Vídeo Utilizando HTTP Live Streaming

Trabalho de Conclusão de Curso apresentado ao Instituto Superior Tupy - IST, como parte dos requisitos para a obtenção de grau de Bacharel de Sistemas de Informação, sob a orientação da professora Edicarsia Barbiero Pillon.

Joinville 2011/2

J EFFERSON R AFAEL KOZERSKI

Trabalho de Diplomação sob o título Distribuição De Vídeo Utilizando HTTP Live Streaming, apresentado por Jefferson Rafael Kozerski, examinado e aprovado em 08 de dezembro de 2011, em Joinville, dando ao seu autor o grau de Bacharel de Sistemas de Informação, pela banca examinadora constituída conforme abaixo:

MSc. Edicarsia Barbiero Pillon - SOCIESC

MSc. Paulo Marcondes Bousfield - SOCIESC

Esp. Claudinei Dias - SOCIESC

Primeiramente dedico este trabalho à Deus, que me deu forças e iluminou meu caminho; à minha amada esposa Patrícia, pelo carinho, paciência, compreensão, incentivo e dedicação para comigo durante os anos de faculdade e, em especial nesta fase final.

AGRADECIMENTO

A Deus, por sua eterna bondade e ter tornado possível essa realização. A meus pais, Nadir e Terezinha, que sempre me incentivaram. Aos demais amigos, familiares, professores e colegas que, de forma direta ou indireta, ajudaram-me nesta conquista.

“No que diz respeito ao desempenho, ao compromisso, ao esforço, à dedicação, não existe meio termo. Ou você faz uma coisa bem-feita ou não faz.” Ayrton Senna

RESUMO A internet hoje está experimentando um grande crescimento na quantidade de tráfego devido ao número elevado de usuários consumindo streaming de mídias. A facilidade de conexão com a rede mundial de computadores cresce exponencialmente a cada dia com a existência de dispositivos cada vez mais acessíveis e com a internet móvel sendo implantada em ritmo acelerado se comparado com a última década. Porém, mesmo que a facilidade de conexão tenha tornado possível à inserção de muitas novas pessoas à internet, sua capacidade de transferência evoluiu de forma menos acentuada, juntamente com os dispositivos móveis, que em sua maioria, possuem processamento de dados limitados. As discrepâncias nas velocidades de transferências de dados entre conexões de internet móvel e conexões de banda larga criaram um desafio aos pesquisadores, que devem encontrar meios que possibilitem entregar arquivos de mídia a usuários finais com dispositivos que possuem processamentos de dados limitados de forma satisfatória. Ou seja, sem interrupções e com a maior fidelidade de som e imagem possível aos usuários que se tornam mais exigente a cada dia. Entre os meios de distribuição de streaming de mídia existentes atualmente, encontra-se o método de streaming adaptativo. Este método aproveita-se da possibilidade de velocidades de conexões diferentes entre seus utilizadores, entregando a eles, de forma diferenciada, os formatos de vídeo que melhor se adapte a ocasião. Desta forma, é possível entregar arquivos com qualidades satisfatórias aos telespectadores, diferenciando-os de acordo com capacidade dos seus dispositivos e velocidades das suas conexões. Este trabalho propõe o estudo da tecnologia de streaming, bem como entendimento da sua evolução durante a massiva disseminação da internet, a fim de conhecer seus métodos alternativos de distribuição, com foco em streaming adaptativo. Ainda, entender algumas das principais ferramentas de distribuição de streaming adaptativos presentes no mercado atual. Como foco deste trabalho, estudar o método de distribuição HTTP Live Streaming, o qual é o primeiro método de distribuição de streaming adaptativo a ser proposto como documentação oficial em RFC, com o intuito de tornar-se um padrão de distribuição de streaming. Com este estudo, desenvolveu-se um protótipo funcional, capaz de utilizar-se das técnicas de HTTP Live Streaming para a geração de streaming adaptativo, sem a necessidade de modificações em ambientes de distribuição ou recepção de mídia, a fim de diminuir custos e facilitar a implementação de ambientes de streaming de mídia. Palavras-chave: HTTP Live Streaming. Streaming Adaptativo. distribuição de vídeo.

ABSTRACT Internet nowadays is undergoing a large increase in traffic due to the high number of users who are streaming media. It has become so easy to connect to the World Wide Web in computers, which has increased exponentially, as each day devices come into being which have become more accessible and by way of the advent of mobile internet implementation at an accelerated rate as compared to the previous decade. However, even though connection facilities have made it possible for many new people to be inserted into the internet, transfer capacity has evolved much less accentuated, along with mobile devices, which mainly have limited data processing power. The discrepancies in data transfer speeds among mobile internet connections and broad band connections have created a challenge for researchers, who must find the means to make media file delivery satisfactorily to final users who utilize limited data processing devices. This means it is necessary to provide, without interruptions and enhanced fidelity in sound and image quality, in order to satisfy users who have become more and more demanding. The adaptive streaming method is one of the streaming solutions currently employed. This method takes advantage of varied connection speeds among users, delivering streaming to them at different rates in the best video formats which adapt to each particular occasion. This way, it is possible to delivery files at acceptable quality to the viewer and to stream to the devices based on the capacity and speed of their particular connection. This paper proposes to study streaming technology, as well as to understand the evolution during the massive internet dissemination, for the purpose of discovering alternative transference methods, focused on adaptive streaming. The research has also sought to understand the main adaptive streaming tools currently on the market. The HTTP Live Streaming distribution method has also been focused in this paper, which is the first method for adaptive streaming distribution to be proposed as an official document in RFC, for the purpose of making this a become a standard streaming distribution method. A functional prototype has been developed in this research paper, which is capable of applying the HTTP Live Streaming techniques for generating adaptive streaming , without any need of modifying distribution interfaces or capturing media, in order to decrease costs and facilitate the implementation of media streaming interfaces. Keywords: HTTP Live Streaming. adaptive streaming. video distribution.

LISTA DE ILUSTRAÇÕES Figura 1 − Uma analogia download e streaming com o ato de beber água . . . . . . . . . . 20 . . 23

Figura 2 − Uma representação do funcionamento do HTTP progressive download

Figura 3 − Exemplo de uma primeira mensagem de requisição HTTP, por um arquivo de vídeo em um servidor web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Figura 4 − Exemplo de uma mensagem de requisição HTTP, por um fragmento de arquivo de vídeo em um servidor web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Figura 5 − Uma representação do funcionamento da entrega de HTTP streaming adaptativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 . . . . . . . . . . . . . 36 . . . . . . 41

Figura 6 − Exemplo de um código fonte HTML5 com elemento <video>

Figura 7 − Fluxograma do funcionamento da entrega de HTTP Live Streaming Figura 8 − Exemplo de um arquivo .M3U8

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 . . . . . . . . . . . . 44

Figura 9 − Exemplo de um arquivo .M3U8 com variações de taxa de bits Figura 10 Exemplo gráfico de arquivos de índice alternativos −

. . . . . . . . . . . . . . . . . . . . . . . 44

Figura 11 Exemplo de um arquivo .M3U8 com índices alternativos para Proteção Failo− ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Figura 12 Fragmento de uma arquivo “.htaccess” com as linhas de configuração para − HTTP Live Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Figura 13 Modelo da sintaxe genérica para FFmpeg − Figura 14 Modelo da sintaxe genérica para FFmpeg −

Figura 15 Exemplo de um arquivo batch para a fragmentação de vídeo utilizando FFm− peg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 . 54

Figura 16 Exemplo de organização de pastas criadas pelo “PHP HLS Fragmenter ” −

Figura 17 Arquivo mestre final, criado para utilizar os arquivos gerados pelo “PHP HLS − Fragmenter ” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 37

Quadro 1 − Comparação entre TCP and UDP

Quadro 2 − Introdução do suporte de vídeo para HTML5 nos principais navegadores web Quadro 3 −
Suporte de vídeo HTML5 em alguns sites de vídeo de grandes publicações

(social e comercial)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 . . . . . . . . . . . 45

Quadro 4 − Atributos de identificação de URI para tag #EXT-X-STREAM-INF Quadro 5 − MIME type específico para cada extensão de arquivo

. . . . . . . . . . . . . . . . . . . . . . 46 . 48

Quadro 6 − Exemplos de combinações de fatores para compressão de dados para HLS

Quadro 7 − Exemplos de opções de parâmetros para conversão de vídeo utilizando FFmpeg

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

LISTA DE SIGLAS TCC Trabalho de Conclusão de Curso BSI Bacharelado em Sistemas de Informação IST Instituto Superior Tupy EAD Educação a distância RTP Real-time Transport Protocol RTCP Real-Time Transport Control Protocol HTTP Hypertext Transfer Protocol UDP User Datagram Protocol RFC Request for Comments IETF Internet Engineering Task Force ITU International Telecommunications Union ISO International Organization for Standardization IEC International Electrotechnical Commission WWW World Wide Web ADSL Asymmetric Digital Subscriber Line WLAN Wireless Local Area Network IEEE Institute of Electrical and Electronics Engineers TCP Transmission Control Protocol URL Uniform Resource Locator

SUMÁRIO 1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 DISTRIBUIÇÃO DE VÍDEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 16 18 19 20 22 26 27 36 40 49 57 59 62

2.1 MÉTODOS DE TRANSMISSÃO DE MÍDIA

2.1.1 Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Streaming Tradicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 HTTP Progressive Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.4 HTTP streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 HTTP STREAMING ADAPTATIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 CODECS E CONTÊINER PARA VÍDEO STREAMING ADAPTATIVO . . . . . . . . . 3 HTTP LIVE STREAMING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 CODIFICANDO ARQUIVOS DE VÍDEO COM FFMPEG 4 CONCLUSÃO

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . APÊNDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

1

INTRODUÇÃO

É evidente que na era digital em que se está atualmente inserido, os métodos de comunicação mudam constantemente aperfeiçoando-se conforme o avanço tecnológico dos meios de comunicação. As interações “face-a-face” têm sido substituídas de maneira rápida pelos indivíduos, que também demonstram grande aceitação e muito interesse em métodos que utilizam a Internet como ponte entre os interlocutores. As formas de comunicação, que minimizam os efeitos da distância como e-mails ou serviços de bate-papo virtual, não mais trabalham sozinhas, mas fazem parte de um ou vários aplicativos, cuja forma principal é a utilização de conteúdos em formato de vídeo, como, por exemplo, videoconferência. Com o intuito de ampliar a discussão, pode-se iniciar o entendimento de como era o funcionamento das entregas de vídeo durante o surgimento massivo da Internet. Para a entrega dos vídeos utilizando a Internet, entre o fim da década de 1980 e o início da década de 1990, o conteúdo era gravado e armazenado em computadores remotos, por sua vez, chamados de servidores. Os espectadores, utilizando seus computadores que poderiam estar tanto em suas residências como também em centros educacionais, deveriam acessar esse vídeo por um navegador de Internet utilizando um endereço eletrônico. O vídeo então entrava no processo de descarregamento, comumente conhecido por download. O download era um processo prático, porém, em determinados momentos, tornaria-se estressante para o usuário, pois interferências na conexão poderiam ocasionar oscilações e corromper o arquivo que estava sendo descarregado. Esta dificuldade aumentava ainda mais quando o tamanho físico do vídeo era demasiadamente grande, o que também causava uma longa espera até completar o download. Esse tempo era necessário, uma vez que para visualizar o vídeo era preciso tê-lo por completo na máquina local do usuário. A entrega de vídeo para os espectadores foi revolucionária no âmbito de ensino a distância. Com o crescimento da Internet como meio de educação e com a absorção rápida de vídeo baseado em tecnologias de streaming que, por sua vez, não requeriam o completo descarregamento dos vídeos para poderem ser visualizados. Streaming pode ser definido como a possibilidade de visualizar o conteúdo do áudio ou vídeo, sem a necessidade de tê-lo salvo no computador local (KUROSE; ROSS, 2010), além de ser um método estável para a disponibilização de áudio e vídeo. Por outro lado, para algumas instituições de ensino, por exemplo, o processo de implantação de tecnologias de distribuição de conteúdos audiovisuais ainda pode ser considerado demorado e custoso, pois por mais que os equipamentos e tecnologias para a produção de

13

vídeo tiveram decréscimos significativos de preços nos últimos anos (ADAO, 2006), há a necessidade de um mínimo de requisitos, entre os quais se destaca a necessidade de um servidor dedicado ao streaming de vídeo. Outro ponto que pode ser analisado é que o custo para manter um servidor de streaming de vídeo ainda possui um valor elevado. Além disso, o streaming de vídeo, em seu conceito principal, também chamado de tradicional streaming, utiliza o Procolo de Transporte em Tempo Real - RTP (Real-time Transfert Protocol), onde normalmente são barrados em firewalls, ou ainda encontra dificuldades para visualização ao ser utilizado em dispositivos móveis, como celulares, pois necessitam de aplicações específicas para se adaptar a este método de distribuição (ISLAM, 2010). Nos anos recentes, pode-se notar uma grande quantidade de provedores de conteúdo utilizando HTTP Streaming como principal método de distribuição de vídeo. Segundo Islam (2010), isso se deve a quatro fatores: o valor de streaming, baseado no Protocolo de Transferência de Hipertexto (HTTP), tem custo menor que os serviços de distribuição de mídias oferecidos por provedores de hospedagem de vídeo; HTTP Streaming geralmente pode contornar firewalls, pois a maioria dos firewalls permitem o tráfego de pacotes HTTP na porta 80, vindo da Internet - enquanto a maioria bloqueia tráfego User Datagram Protocol (UDP), que é amplamente utilizado nos métodos padrões de streaming; a distribuição utilizando HTTP funciona com qualquer web cache, sem a necessidade especial de alterações em proxies e caches; o custo para entregar os dados utilizando HTTP é muito mais barato que com outros protocolos. A utilização de HTTP Streaming ganhou imensa popularidade devido às vantagens citadas. Neste trabalho aborda-se o HTTP Streaming Adaptativo, tendo como delimitação a sua análise de funcionamento e aplicação em um ambiente de ensino. Considera-se a possibilidade de o usuário gerar o conteúdo, armazená-lo em servidores de distribuição e ser capaz de incorporá-lo a fim de disponibilizá-lo aos usuários finais, com facilidade e compatível com a maioria dos dispositivos conectados a Internet atual. Diante disso, questiona-se: Como desenvolver uma ferramenta de distribuição de conteúdo audiovisual que utilize mínimos recursos necessários, requeira mínimas alterações no sistema operacional e não necessite de alterações em ambientes de proxies, sem interferir na qualidade audiovisual do conteúdo recebido pelos espectadores? Há de se citar também que a quantidade de dispositivos conectados a Internet atualmente vai além de somente computadores de mesa, chegando até aos dispositivos móveis como celulares com hardwares extremamente pequenos e com processamentos limitados. Estes também podem ser utilizados como clientes para entrega de streaming, porém com uma

14

abordagem diferente, visto o limite de largura de banda e o poder de processamento atuais destes dispositivos. A partir daí, analisando os recursos disponíveis e as premissas para o desenvolvimento da ferramenta proposta neste projeto, pode-se afirmar que o estudo das tecnologias para a distribuição de conteúdos audiovisuais torna-se o principal foco para o sucesso da implementação de uma aplicação para captura, distribuição e recepção audiovisual (THORNHILL; ASENSIO; YOUNG, 2002). Pode-se ainda citar que o tema proposto demonstra-se relevante ao verificar-se a existência, em fase de desenvolvimento, de uma RFC1 proposta pela empresa Apple, com a finalidade de especificar e documentar a forma de distribuição de vídeos utilizando HTTP Live Streaming (PANTOS, 2011). Vale relembrar que a existência de ferramentas disponíveis, criadas sobre os princípios de código aberto, padronizadas e que possuam facilidade na implementação ainda são escassas, colocam o tema em uma perspectiva oportuna para o momento. O resultado obtido com estes estudos será importante para o desenvolvimento da ferramenta proposta neste trabalho, e também para trabalhos posteriores. Além de se tornar um estudo em potencial, contribuirá para que outras áreas importantes como a Educação a Distância (EAD), por exemplo, possam reduzir custos ou até mesmo a necessidade de implementação de grandes arquiteturas de distribuição de vídeo. Com isso, possibilitar então enriquecer ainda mais os conteúdos audiovisuais distribuídos aos alunos. O objetivo geral deste trabalho é compreender o funcionamento de distribuições de streaming adaptativas, com foco principal no método HTTP Live Streaming como tecnologia de distribuição. Para atingir o objetivo geral, formularam-se os seguintes objetivos específicos: levantar os principais requisitos necessários para um sistema de captura, distribuição e recepção de vídeo e áudio; pesquisar métodos para compressão de vídeo disponíveis para HTTP Live Streaming; desenvolver a aplicação modelo, capaz de utilizar-se da captura de um sinal de vídeo, codificá-lo e transmiti-lo utilizando HTTP Live Streaming, bem como recebê-lo e reproduzi-lo satisfatoriamente. Buscar-se-á, com este desenvolvimento, motivar a utilização de método de HTTP Live Streaming, demonstrando a facilidade e o baixo custo para sua implementação, além de motivar o surgimento de novas aplicações com base nos resultados obtidos. Nesta perspectiva, pelo fato de estar destinada a formular problemas, elucidar as dúvidas e construir ideias associadas ao tema escolhido, a metodologia utilizada neste trabalho é uma pesquisa de caráter exploratório. Como procedimento, se desenvolveu pesquisa bibliográRFCs (Request for Comments - pedido de comentários) são documentos padronizados pela Internet Engineering Task Force (IETF), que tendem a ser detalhados e bastante técnicos, e descrevem padrões de cada protocolo da Internet (KUROSE; ROSS, 2010).
1

15

fica em obras de referência, manuais, documentos técnicos e livros introdutórios. A partir daí, o desenvolvimento da ferramenta proposta. Este trabalho estrutura-se em quatro capítulos. Neste capítulo, apresenta-se uma visão geral do trabalho, fato gerador do questionamento da pesquisa realizada, a relevância do tema, o objetivo geral, os objetivos específicos e a metodologia. Como o foco deste trabalho se destaca o método de streaming, cabe ao segundo capítulo uma melhor e mais completa visão e explicação do funcionamento dos métodos de streaming. Esse mesmo capítulo refere-se à fundamentação teórica, base para esta pesquisa, em que se procura evidenciar os conceitos de streaming, a evolução das entregas de vídeo utilizando a Internet assim como suas características. Relata também os métodos de compressão de vídeo de código aberto específicas para HTTP Streaming. O terceiro capítulo aborda uma área específica do método HTTP Live Streaming, o qual é a parte fundamental para o desenvolvimento deste projeto, descrevendo suas vantagens, fatores críticos de utilização e necessidades para implantação. Esse capítulo também é dedicado ao desenvolvimento do aplicativo proposto, desde a escolha do ambiente usado, tenologias e validação da aplicação a ser desenvolvida. E finalmente, o quarto capítulo que será composto da conclusão, abordando o desenvolvimento deste trabalho, inferindo a validação dos objetivos propostos, além das considerações finais e trabalhos futuros.

16

2

DISTRIBUIÇÃO DE VÍDEO

Muito foi feito desde o advento e a disseminação das redes de computadores para além das grandes empresas a respeito das formas e métodos de distribuição de conteúdo multimídia, seja para ensino e aprendizado a distância, seja para teleconferências, marketing, lazer ou outras aplicações. O uso de conteúdo audiovisual vem crescendo exponencialmente a cada dia. Desde a década de 1980, que foi marcada por grandes eventos como a proliferação das redes de computadores, surgiram diversas formas de distribuição e armazenamento de conteúdo audiovisual (KUROSE; ROSS, 2010). Já em 1984, a União Internacional de Telecomunicações (ITU) publicou a padronização do formato de compressão de vídeo H.120, que foi o primeiro padrão de codificação de vídeo digital, o qual serviu como base para o estudo de futuros padrões de codificação (JACOBS; PROBELL, 2007). Ainda nessa década, em 1988, aconteceu o primeiro encontro do grupo de trabalho Moving Picture Experts Group (MPEG), formado pela Organização Internacional de Padronização (ISO), e também pela Comissão Eletrotécnica Internacional (IEC), visando estabelecer padrões internacionais de compressão digital de áudio e vídeo (MITCHELL, 2000). Em 1990, com o padrão H.261, destinado particularmente a aplicações que requeriam codificação em tempo real, iniciou-se a prática de compressão de vídeo digital. Padrão este que seria a base para os próximos desenvolvimentos, permanecendo até os dias atuais (MITCHELL, 2000; JACOBS; PROBELL, 2007). Ainda conforme Ghanbari (2003, p. 2), o MPEG iniciou pesquisas para encontrar técnicas de codificação para armazenamento de vídeos, como CD-ROM. O Objetivo era desenvolver um compressor de vídeo em disco rígido com desempenho comparável aos gravadores de fitas VHF existentes na época. O primeiro padrão desta geração de compressores foi chamada de MPEG-1, que era capaz de realizar a tarefa de compressão com uma velocidade de até 1.5Mbits/s. Ghanbari (2003, p. 2) cita que com padrão MPEG-1 o tempo para a tarefa de compressão e descompressão de um vídeo armazenado, na época, era eficaz a ponto de não gerar grandes constrangimentos. De acordo com Kurose e Ross (2010), o principal evento da época foi o surgimento da World Wide Web (WWW), que levou a Internet para os lares e as empresas de milhões de pessoas no mundo inteiro. A possibilidade de distribuição de conteúdos diversos, de forma facilitada pela Internet, fez despertar a inovação em diversos desenvolvedores da época. Em pouco tempo começaram

17

a existir aplicativos gráficos, denominadas browsers para a navegação na Internet. A Word Wide Web fez surgir centenas de aplicações, e dentre elas serviços multimídia em tempo real. Neste contexto, Kurose e Ross (2010, p. 44) descrevem ainda que as pesquisas e desenvolvimentos de redes na década de 1990 tiveram progressos notáveis no desenvolvimento de dispositivos roteadores e roteamento de alta velocidade. Esses avanços impulsionaram ainda mais o desenvolvimento de redes de alta velocidade. Surgiram ainda nessa época outros formatos de compressão de vídeo, sucessores ao MPEG-1, como MPEG-2/H.262, com suporte a compressões de vídeos com maior resolução e velocidades de compressão e descompressão ainda maiores, e por consequência significativo aumento de qualidade audiovisual. Foi nessa década que se iniciou, de forma mais alargada, a distribuição de conteúdo em tempo real. Em 1995, a empresa pioneira na área de distribuição de áudio e vídeo, a RealNetworks, liberou a primeira versão do produto chamado RealAudio, o primeiro produto até então distribuído para utilização de streaming de áudio pela Internet. O produto incluía um codificador de áudio, um servidor de mídia e também um player 1 para executar o áudio enviado por este servidor. No ano consecutivo ao seu lançamento, o RealAudio permitiu aos usuários não apenas selecionar e receber áudio diretamente, mas também distribuir conteúdos sob demanda, o que rapidamente se tornou popular entre empresas de entretenimento, instituições de ensino e canais de notícias (KUROSE; ROSS, 2010, p. 607). Juntamente com a inovação gerada pela RealNetworks, surgiram também novos protocolos de distribuição de mídia em tempo real, como o Real-Time Streaming Protocol (RTSP) (SCHULZRINNE, 1998), um protocolo que estabelece e controla as conexões entre um ou mais fluxos contínuo de mídia, como áudio ou vídeo. Em decorrência da massiva aceitação do mercado a esta nova forma de distribuição de conteúdo audiovisual, outras empresas como Microsoft e Apple iniciaram os seus desenvolvimentos na área. A partir do início da década de 2000, a penetração significativa da Internet nas residências preparou um ambiente de grandes variedades de novas aplicações multimídia. Outro aspecto que se pode ressaltar é que, nessa mesma década, surgiram novos dispositivos de armazenamento de dados de grande capacidade. Eventos esses que influenciaram diretamente na diversificação das formas de distribuição de streaming. Em 2003, foi proposto o formato definitivo do padrão de compressão H.264 (RICHARDSON, 2003), que podia prover serviços para aplicações gráficas interativas e multimídia, em especial na Word Wide Web, satisfazendo as
1

Tocadores de arquivos de áudio e vídeo

18

necessidades de autores, provedores de serviço e usuários finais (LIM; SINGER, 2006) (PANSANATO, 2005). Parte-se do pressuposto que esses avanços tornaram os usuários mais críticos quanto a qualidade audiovisual dos conteúdos a eles apresentados. Esta exigência sofreu acentuada importância com o surgimento de novas tecnologias de acesso à Internet, incluindo notória atribuição a dispositivos móveis com acesso a Word Wide Web. Diferentes servidores, players e protocolos foram empregados para métodos de streaming. Entre os principais, os serviços de áudio e vídeo de fluxo contínuo armazenado tiveram acentuado crescimento entre os usuários da Internet. Esse método foi difundido pela facilidade imposta por serviços de compartilhamento utilizando um player de vídeo baseado em flash e incorporado nas páginas web. Entre os precursores e bem sucedidos serviços, está o site de compartilhamento Youtube em 2005. Em pouco tempo, o método de fluxo contínuo armazenado se tornou uma das principais formas de distribuição de conteúdo audiovisual na Internet (KUROSE; ROSS, 2010, p. 607). Isso levou vários estudiosos a se dedicarem a criação de novos métodos de compressão e distribuição, com o intuito de diminuir o tráfego na rede necessário para enviar o conteúdo audiovisual ao usuário, e sempre apresentar o conteúdo com maior qualidade possível. Com a grande variedade de velocidades de conexão existentes, e em desenvolvimento, para as redes de distribuição, muitos foram os esforços para desenvolver novos métodos que se adaptassem a essas redes, a fim de utilizar o meio de comunicação da melhor forma possível, sem implicar em constrangimento para o usuário final ou perdas de qualidade do conteúdo entregue (ADAO, 2006; BHANDARKAR; CHATTOPADHYAY; GARLAPATI, 2010). Os métodos de compactação e os formatos que melhor se aplicam ao HTTP Live Stream, serão apresentados posteriormente.

2.1

MÉTODOS DE TRANSMISSÃO DE MÍDIA O método tradicional de transferir um arquivo de um computador remoto a um com-

putador local, utilizando a Internet como meio de comunicação, é comumente conhecido pela palavra inglesa “download”, que pode ter em sua tradução livre para a língua portuguesa como “descarregar”. Com este método, a troca de áudio e vídeo na Internet baseia-se no esquema download-and-play, em que um player, após a requisição do arquivo, é obrigado a aguardar a completa transferência do arquivo e tê-lo salvo na máquina local para então poder executá-lo (TABORDA, 2010). Esse método pode ser considerado usual e prático ao quotidiano quando o produto a ser transferido é de dimensão razoavelmente pequena, no entanto, é incapaz de satisfazer as necessidades do mercado contemporâneo. Para arquivos de grande dimensão, que ocupam

19

grande espaço de armazenamento em disco físico, como um vídeo aula que um professor hospedou em um servidor na Internet, por exemplo, este processo de download se torna um processo custoso, e em determinados momentos com frustrações, por possíveis interrupções na conexão com à Internet. Visto que as interferências na conexão podem corromper os arquivos e, por consequência a necessidade de reiniciar todo o processo, este método é considerado ineficaz quando se faz necessária a transmissão de mídia de fluxo contínuo (ADAO, 2006). Para uma transmissão de mídia de fluxo contínuo, usualmente são utilizados softwares específicos ou até mesmo aplicações específicas instaladas nos servidores de distribuição e um player específico no dispositivo cliente. Com a utilização deste método, apenas a transferência de uma pequena porção do arquivo já é o suficiente para a sua execução. Esta técnica de transmissão de fluxo contínuo recebe o nome streaming. O cliente visualiza o conteúdo dos arquivos de áudio e vídeo de acordo com a quantidade do arquivo transferido. Por exemplo, no momento em que o usuário requisita o início do vídeo, ele pode aguardar alguns segundos até a transferência de uma pequena porção, equivalente a alguns segundos do vídeo para preencher o buffer do player, isso será o suficiente para iniciar a execução e o usuário iniciará a visualização o conteúdo do vídeo.

2.1.1

Streaming

Pela relevância empregada frequentemente ao decorrer deste trabalho, foi considerada pertinente a definição de streaming nesta seção, visando a compreensão mais aprofundada do tema, sintetizando os conceitos básicos e essenciais desta tecnologia. De acordo com Adobe (2001), a tecnologia streaming permite, em tempo real ou sob demanda, acesso a áudio, vídeo ou conteúdo multimídia através da Internet ou em uma intranet. A mídia, em formato streaming, é transmitida por um servidor de mídia especializado ou por uma aplicação específica, e é processada e reproduzida ao usuário por um player específico, tal como é recebida, sem deixar cópias residentes no dispositivo receptor. Ainda pode-se acrescentar que, para a reprodução do conteúdo recebido no player, basta uma pequena espera de tempo inicial para a sincronização e a criação de uma memória temporária, denominada buffer, para armazenar alguns segundos do conteúdo. Esta memória temporária é utilizada para absorver possíveis interrupções na conexão que interferem diretamente no ritmo de recebimento do conteúdo, causando pausas na execução, que podem acarretar em decepções ao usuário que está visualizando o conteúdo (ADAO, 2006). Para exemplificar de forma natural, Kozamernik (2002) faz uma analogia entre a transmissão streaming e o ato de beber água de um copo. A figura 1 exemplifica a analogia, em que o autor descreve que o download comum é como você utilizar uma garrafa para encher um

20

copo de água e, depois de completar, beber a água do copo, e o streaming é como você beber a água diretamente da garrafa.

Figura 1: Uma analogia download e streaming com o ato de beber água
Fonte: adaptado de Kozamernik (2002, p. 2)

Segundo Islam (2010), o streaming está baseado em três métodos gerais: streaming tradicional, download progressivo e HTTP streaming. As subseções a seguir descrevem essas três técnicas de streaming.

2.1.2

Streaming Tradicional

Este método também chamado de True Streaming, ou Streaming “Real”, requer uma arquitetura diferente da usada para download, normalmente utilizando servidores dedicados de distribuição. Ele suporta uma interatividade muito maior com o usuário, garantindo também um grande número de vantagens adicionais. Em uma distribuição de conteúdo utilizando streaming tradicional, quando este não for em tempo real2 , é possível permitir que o espectador possa saltar o tempo de execução do conteúdo audiovisual tanto à frente quanto para trás. Protocolos específicos são utilizados para o transporte de dados entre o servidor e o cliente, gerando a necessidade de aplicativos específicos para a troca de dados entre eles. Um dos protocolos tradicionais streaming é o Real-time Transport Protocol (RTP) (SCHULZRINNE et al., 2003).
Quando citamos as palavras “em tempo real” sobre o assunto de distribuição de vídeo, significa que o cliente recebe um fluxo contínuo com um valor mínimo de atraso, onde a transmissão e recepção do conteúdo é quase instantânea (KOZAMERNIK, 2002).
2

21

O RTP opera utilizando protocolo UDP para o envio dos pacotes de dados. Esta escolha torna o protocolo de transporte simples e eficiente, porém deixa a desejar no âmbito de garantir a entrega dos dados ao cliente. Para fins de entendimento serão comparados os protocolos de transporte UDP e Transmission Control Protocol (TCP), melhor abordado no quadro 1: Quadro 1: Comparação entre TCP and UDP TCP Orientado a conexão - uma conexão é criada antes da transferência de dados. Confiável. Dois canais de comunicação, aumentando a interatividade entre o cliente e o servidor. Correção de erros. Controle de fluxo. Gerencia a taxa de download. Reenvia pacotes perdidos. Não predetermina taxa de entrega. O TCP irá aumentar a taxa de dados até que haja perda de pacotes que indique congestionamento. UDP Não orientado a conexão - não há necessidade de estabelecer uma conexão. Não confiável. Unidirecional, sem interatividade, apenas iniciar e parar. Somente detecta os erros, faz uma verificação dos dados - checksum. Não possui controle de fluxo. Não reenvia pacotes perdidos. A taxa de entrega deve coincidir com a taxa de fluxo codificado. Diferentes codificações para um mesmo conteúdo pode ser necessário para ajustar diferentes canais de entrega com taxa de entrega variável. Sem cache local - os pacotes são processados pelo player multimídia conforme são recebidos

Tolerância de buffer overflow: se os dados chegarem rápido demais, o receptor envia mensagem para o servidor para desacelerar o envio

Fonte: adaptado de Kozamernik (2002, p. 8)

Apenas com a missão de transportar os dados entre o cliente e o servidor, o protocolo RTP necessita de um controle de sessão do cliente, e também de um canal para o cliente enviar comandos ao servidor, como, por exemplo, a ação de pausar, parar ou continuar a reprodução. Para sanar esta necessidade, foi criado o protocolo de controle Real-Time Transport Control Protocol - RTCP (SCHULZRINNE et al., 2003). Atualmente o protocolo padrão para emissão de comandos de controle é o RTSP. De acordo com Schulzrinne (1998, p. 4):
O RTSP estabelece e regula um único ou vários fluxos sincronizados de mídias contínuas ao mesmo tempo. Ele não costuma entregar os fluxos contínuos em si, embora a intercalação do fluxo de mídia contínua com o fluxo de controle seja possível. Em outras palavras, RTSP age como um “controle remoto” para servidores multimídia.

22

Agindo como controle remoto, existe a possibilidade do cliente requisitar alterações no conteúdo enviado pelo servidor. Se a velocidade de conexão entre o cliente e o servidor diminuir durante a reprodução, uma das alterações que pode ser realizada é alternar entre as qualidades disponíveis do vídeo que está sendo enviado pelo servidor, com o objetivo de não gerar pausas na reprodução do conteúdo. Apesar de não fazer parte do foco deste trabalho, se faz interessante citar que o uso do streaming tradicional proporciona um grau de segurança maior sobre outros métodos de distribuição, quando o conteúdo em transmissão contém direitos autorais. Isso se dá por que neste método, usando UDP como protocolo de transporte, o conteúdo enviado ao player do receptor não é armazenado no cliente e nem permanece como arquivo temporário no disco rígido do dispositivo receptor. O player simplesmente recebe o conteúdo, o decodifica e o exibe ao mesmo tempo que descarta logo após a sua exibição (KOZAMERNIK, 2002; LARSON; COSTANTINI, 2007). Por outro lado, uma grande maioria dos firewalls bloqueia todos os tráfegos UPD, e também pelas circunstâncias positivas que aparentam ser maiores, visto no quadro 1, faz com que cada vez mais se utilize aplicações que atuem sobre TCP (PFEIFFER, 2010). Nesta perspectiva, existe um método de distribuição que é comumente utilizado e teve um aumento expressivo de uso com a facilidade de implementação, pois não requer grandes modificações ou complexos sistemas de distribuição. Este método é conhecido como HTTP progressive download.

2.1.3

HTTP Progressive Download

Recapitulando o entendimento do método de download, descrito no início desta seção, em que cita a facilidade de distribuição de arquivos de vídeo por intermédio de descarregamento, o método HTTP progressive download para áudio e vídeo na web é um dos métodos mais utilizados atualmente (ISLAM, 2010). O HTTP progressive download é hibrido entre o streaming tradicional e o “download”, utiliza o protocolo HTTP como protocolo de transporte. Como o protocolo HTTP é um protocolo stateless (sem estado), onde cada conexão com o servidor é tratada como uma conexão nova, cabe a aplicação manter o controle da conexão. Além disso, o HTTP roda sobre protocolo TCP, que como visto no quadro 1, é uma das principais diferenças entre o UDP e o TCP. Esse último utiliza várias técnicas para proporcionar confiabilidade na entrega dos dados (KUROSE; ROSS, 2010). Daras e Ibarra (2009) relembram ainda que este método consiste na utilização de um arquivo de mídia previamente gravado e armazenado em um servidor Web, porém diferencial-

23

mente do método de download comum, com o HTTP progressive download, o cliente começa a reproduzir o conteúdo de mídia antes mesmo do download completo do arquivo. Para uma melhor utilização deste método, é comumente utilizado um player específico para a recepção e a execução do conteúdo audiovisual. A medida que este player recebe o arquivos que está sendo descarregado do servidor, ele armazena estes dados em uma memória temporária do player denominada buffer. Esta memória é utilizada exclusivamente para absorver alterações do ritmo de recepção dos dados, ou até mesmo para inibir pausas causadas por falhas na conexão. Também diferente do método streaming tradicional, no HTTP progressive download, o arquivo que é requisitado ao servidor é recebido em fragmentos do arquivo completo. Nesta situação, conforme o recebimento dos fragmentos, o arquivo é automaticamente unido com cada parte recebida, e este, por sua vez acaba por ser salvo no dispositivo de armazenamento físico do cliente, normalmente na pasta de cache do browser. Uma representação do processo é descrita na figura 2.

Figura 2: Uma representação do funcionamento do HTTP progressive download
Fonte: adaptado de Daras e Ibarra (2009, p. 221)

Utilizando este método, é possível saltar de uma posição de tempo de execução do áudio ou vídeo, para outra que foi previamente carregada no buffer do player. Como descrito anteriormente, este método proporciona o salto de tempo somente quando o player possui um buffer e a posição de salto estiver previamente completa no buffer. Novos métodos foram desenvolvidos a partir do funcionamento do HTTP progressive download, a ponto de melhorar a experiência com o usuário.

24

Para sanar a necessidade de permitir que o utilizador possa saltar o tempo de execução para uma posição que não foi previamente descarregada, foi criada uma derivação do HTTP progressive download nomeado de Seek streaming, também chamado de Pseudo streaming (TABORDA, 2010). O cabeçalho de mensagem, do protocolo HTTP em sua versão 1.1, possui um campo chamado Accept-Ranges que torna possível a utilização do Seek Streaming (BERNERS-LEE et al., 1999). Quando a aplicação faz a primeira requisição do conteúdo por intermédio de uma Uniform Resource Identifier - URI, caso a resposta do servidor seja positiva, normalmente envia no cabeçalho da mensagem de resposta o tamanho em bytes do arquivo requisitado. A aplicação, sabendo o tempo e o tamanho do arquivo através dos cabeçalhos de resposta HTTP, normalmente exibe para o utilizador uma barra demonstrando o buffer de carregamento do conteúdo em forma temporal. Quando o utilizador salta para uma determinada posição de tempo do player, a aplicação faz a requisição passando como valor ao parâmetro Ranges no cabeçalho HTTP, os bytes referente a posição temporal do arquivo. Este valor deve obrigatoriamente ser um número real inteiro que compreenda entre zero e o total de bytes do arquivo.

1 2 3 4 5

GET / v i d e o . webm HTTP / 1 . 1 Host : 1 2 7 . 0 . 0 . 1 Connection : keep−a l i v e R e f e r e r : h t t p : / / 1 2 7 . 0 . 0 . 1 / v i d e o . webm Range : b y t e s=0−

Figura 3: Exemplo de uma primeira mensagem de requisição HTTP, por um arquivo de vídeo em um servidor web

1 2 3 4 5

GET / v i d e o . webm HTTP / 1 . 1 Host : 1 2 7 . 0 . 0 . 1 Connection : keep−a l i v e R e f e r e r : h t t p : / / 1 2 7 . 0 . 0 . 1 / v i d e o . webm Range : b y t e s =50422827 −60636159

Figura 4: Exemplo de uma mensagem de requisição HTTP, por um fragmento de arquivo de vídeo em um servidor web Pode-se notar que, na figura 3, o campo Range possui como primeiro valor byte o valor zero, não informando o segundo valor. Estes dois valores separados por um hífen são enviados ao servidor como parâmetro de intervalo esperado como retorno. Ao contrário da figura 3, na figura 4, pode-se observar que o campo Range possui os dois valores preenchidos. O primeiro valor é dedicado a descrever ao servidor o byte inicial, enquanto o segundo valor é dedicado a

25

descrever o byte final esperado. Caso o segundo valor esteja ausente ou tenha um valor maior que o tamanho total do arquivo, é considerado que o valor final seja o último valor de byte do arquivo (BERNERS-LEE et al., 1999). Assim, é facilmente verificável que, graças a este aspecto, torna-se possível pausar o descarregamento na sua aplicação e recomeçar o descarregamento de arquivos por uma conexão HTTP. Aponta-se agora outra peculiaridade que, pela utilização do protocolo HTTP, qualquer servidor web (como, por exemplo, Apache ou Intenet Information Service - IIS) pode ser utilizado como servidor de distribuição dos arquivos de áudio e vídeo sem grandes necessidades ou mudanças na infraestrutura (ISLAM, 2010). Pode-se ainda, encontrar a citação de HTTP Fake streaming referenciando a utilização de scripts no lado servidor para a utilização de streaming, e este recebendo o nome de HTTP streaming. Antes de prosseguir com a apresentação deste método, é necessário explanar melhor este funcionamento de distribuição que se assemelha em vários aspectos com o HTTP streaming, porém nativamente utiliza HTTP Progressive Download por meio de Pseudo streaming. Esses scripts, ao receberem uma requisição para descarregamento de um arquivo, iniciam um processo de leitura de um arquivo que está armazenado fisicamente no servidor, e sequencialmente envia partes deste arquivo completo para a aplicação que o requisitou. Enquanto o HTTP Progressive Download permite saltar um período temporal de um conteúdo previamente carregado no buffer de um player, no HTTP Fake Stream, o player que está sendo utilizado pelo cliente permite ao usuário realizar a tentativa de salto para um período temporal do conteúdo que ainda não foi previamento carregado no buffer. Essa peculiaridade só é possível na utilização de arquivos de vídeo que foram codificados utilizando keyframes inseridos no arquivo o qual é enviado à aplicação cliente que fará a reprodução do vídeo. Os keyframes, presentes em formato de texto na sessão de metadados do cabeçalho HTTP, são necessários para que o player possa configurar a timeline do vídeo. Estes metadados normalmente não ultrapassam mais do que vários kilobytes (PFEIFFER, 2010). Pfeiffer (2010) relembra que metadados é um termo utilizado em vários e diferentes contextos com vídeo, por isso é necessário compreender o contexto para entender o que exatamente está sendo referido pelo atributo. A partir deste momento, o aplicativo envia uma requisição para o servidor, que é recebido pelo script que está servindo o conteúdo. Esta nova requisição contém, junto ao nome do arquivo requisitado, um valor, informando ao script a partir de qual posição do arquivo ele deve iniciar a leitura e então responder ao aplicativo que o requisitou.

26

Tiwari e Elrom (2010) descrevem em seu livro a utilização da linguagem de programação server-side Hypertext Processor (PHP), chamando essa utilização de PHP streaming. Logicamente este nome se deve pelo fato da utilização da linguagem PHP como principal script para essa tarefa. Por isso, pode-se encontrar a mesma forma de trabalho, com nomes de outras linguagens de programação server-side, capazes de realizar manipulações de arquivos localmente, antecedendo o nome streaming, dando referência ao script utilizado. Porém ainda assim, o método utilizado para entrega do conteúdo é o HTTP Streaming. Pode-se citar um problema quanto a utilização de HTTP progressive download: a menos que o fluxo de mídia seja encerrado, todo o arquivo será baixado para o cliente. Islam (2010) relembra que após o player ter requisitado a mídia utilizando o HTTP progressive download, mesmo que o usuário interompa o player de mídia, o arquivo continua sendo enviado pelo servidor até seu timeout, utilizando os recursos de transferência de dados do servidor.

2.1.4

HTTP streaming

Como descrito nas sessões anteriores, poucas ou quase nenhuma modificação é necessária no servidor web para servir streaming por HTTP. O benefício de estar onipresente na Internet, juntamente com o baixo custo e a facilidade para implementação, sem necessidade de modificações no ambiente do servidor web, tornou-se rapidamente o método popular de distribuição de conteúdos audiovisuais. Consecutivamente, fornecedores de conteúdo aceitaram e vem difundindo amplamente a utilização de HTTP progressive download enquanto desenvolvem seus próprios métodos e características para melhorar o streaming por HTTP (PFEIFFER, 2010). É importante ressaltar que, neste trabalho, a afirmação “não haver necessidade de realizar modificações no servidor web”, deseja-se tornar claro que servidores de hospedagem normalmente disponíveis na Internet possuem um padrão de configurações e aplicações instaladas em seu sistema operacional, e esses em sua grande maioria não possibilita alterar configurações ou realizar instalações de outros aplicativos. De modo geral, qualquer extensão de software aplicativo utilizado para possibilitar o streaming de mídia não pode ser instalado em servidores de hospedagem que não permitam tais modificações. Esclarecido esse aspecto, volta-se outra vez à questão do método de distribuição de streaming sobre conexões HTTP. Pfeiffer (2010) cita que é uma característica em particular que tem feito com que os fornecedores criem novas tecnologias, métodos de distribuição para aproveitar ao máximo as características positivas de transmissão de conteúdo utilizando protocolo HTTP. Dentre a mais notória está a transmissão adaptável por HTTP.

27

O HTTP streaming adaptativo, descrito de forma sucinta por Pfeiffer (2010), consiste na entrega do vídeo ao usuário dependendo exclusivamente das condições da rede e do software do usuário, tal como o ambiente atual, a fim de garantir a melhor experiência possível para o telespectador.

2.2

HTTP STREAMING ADAPTATIVO O HTTP streaming é realmente adaptativo quando analisamos a forma como ele trata

o conteúdo de entrada, ou seja, o arquivo de vídeo a ser enviado pelo servidor. O arquivo de entrada é dividido em uma série de pequenos arquivos, os quais, no presente trabalho adotase a nomenclatura “fragmentos” para representá-los. Cada um destes fragmentos pode ser codificado em um ou mais formatos, e posteriormente enviados a um servidor Web para servir como entrega aos clientes. Posteriormente, o cliente solicita os fragmentos do servidor usando a técnica de download progressivo. De acordo com Islam (2010), a definição de adaptação é baseada pelo ato do player cliente escolher uma versão com formato específico de cada fragmento. A versão do fragmento solicitado pelo cliente é baseada em uma estimativa das condições atuais da rede e da carga sobre o servidor. Em situações em que a rede ou o servidor estiver sobrecarregado, por exemplo, o cliente então solicita uma versão com características pequenas, normalmente com uma qualidade audiovisual mais baixa. Caso contrário o cliente solicita uma versão de maior qualidade, ou seja, proporcionando uma maior resolução e maior fidelidade de cores. A figura 5 demonstra a entrega dos fragmentos de mídia requisitados pelo cliente.

Figura 5: Uma representação do funcionamento da entrega de HTTP streaming adaptativo
Fonte: adaptado de Zambelli (2009, p. 8)

28

Pfeiffer (2010) descreve que recentemente o grupo MPEG vem trabalhando na padronização de uma especificação para HTTP streaming adaptativo, o qual eles nomearam de Dynamic Adaptive Streaming for HTTP (DASH) na publicação do primeiro draft deste padrão de desenvolvimento durante sua reunião 933 na cidade de Geneva no estado de Switzerland. DASH especifica os formatos que permitem a entrega de mídia através de servidores HTTP padrões para clientes HTTP. O grupo MPEG prevê alcançar o status final para publicação, aproximadamente, em novembro de 2011. No entanto, Pfeiffer (2010) também afirma que existe, em paralelo ao DASH, projetos sendo discutidos para uso de CODECs de código aberto em geral, pelo Web Hypertext Application Technology Working Group (WHATWG)4 , que é formado por pessoas com interesses em comum voltados a evolução do HTML e de tecnologias ligadas a tal. Afirma ainda que há uma expectativa que no ano de 2012, seja criado uma solução genérica e de código aberto para a utilização de HTTP streaming adaptativo. Por enquanto, como não existe uma padronização para a utilização desta tecnologia, vários fornecedores ao ver a potencialidade da utilização desta tecnologia, estão criando suas próprias extensões para melhorar a forma de distribuição de vídeo sobre HTTP. Dentre as soluções de fornecedores que estão disponíveis no mercado e que se destacam no avanço ao utilizarem HTTP streaming adaptativo, se fazem notórios três: Microsoft Smooth Streaming, Adobe HTTP Dynamic Streaming e Apple HTTP Live Streaming (PFEIFFER, 2010). Cada uma destas novas extensões possui características que as diferem das demais, assim como a utilização de CODECs padrões para compressão de áudio e vídeo. Em algumas, há a separação de canais de áudio e vídeo em uma comunicação streaming, em outras o funcionamento da adaptação servida aos player de conteúdo. As três soluções citadas acima, que se destacam entre as existentes, serão descritas a seguir com o intuito de diferenciá-las.

2.2.0.1

Microsoft Smooth Streaming O Microsoft Smooth Streaming foi desenvolvido utilizando a característica de transportar

streaming sob conexões HTTP. Ele necessita que o servidor de distribuição seja um IIS com pacote de extensão IIS Media Services instalado, além do aplicativo Expression Encoder para a codificação do vídeo para a sua utilização (MACDONALD, 2009; GHOSH; CAMERON, 2010). Com esta tecnologia, é possível a distribuição de vídeo sob demanda e também ao vivo. Para o recebimento e execução da mídia no cliente, é necessário possuir o plugin Microsoft Silverlight instalado no browser cliente para a exibição do player compatível com tal tecnologia.
As reuniões do grupo MPEG são numeradas em ordem crescente a cada novo evento que reúne o grupo Mais detalhes estão acessíveis no endereço eletrônico mantido pelo grupo: http://wiki.whatwg.org/wiki/Adaptive-Streaming
4 3

29

Para a criação do streaming adaptativo, o Smooth Streaming codifica, utilizando o aplicativo Expression Encoder, o conteúdo de uma mesma fonte que normalmente é um arquivo de vídeo de alta definição, em vários níveis de qualidade diferente, porém também completos. O conteúdo então é entregue através do servidor IIS com Smooth Streaming habilitado. O player cliente, ao requisitar a mídia ao servidor IIS, o Smooth Streaming cria fragmentos virtuais dinamicamente a partir de um dos arquivos codificados anteriormente, e os envia sequencialmente ao player cliente. Estes fragmentos virtuais normalmente são separados em espaços de 2 segundos de conteúdo (GHOSH; CAMERON, 2010; MICROSOFT, 2011). O funcionamento do Smooth Streaming é baseado em algumas etapas. Primeiramente um arquivo de vídeo modelo, de alta qualidade, é utilizado para gerar outras cópias deste vídeo com maiores compactações. Cada um dos arquivos gerados pelo Expression Encoder possui uma extensão “.ismv” e cada um deles contém o vídeo original codificado em taxas de bits específicos. Por exemplo, um vídeo, quando codificado a uma taxa de 128bits utilizando o Expression Encoder, gera um arquivo com o final “128.ismv”, e assim sucessivamente para cada taxa de codificação, a fim de organizar e manipular os arquivos finais. Para cada uma das taxas convertidas, o arquivo final “.ismv” contém os fragmentos de 2 segundos, e a forma de armazenamento destes fragmentos no arquivo “.ismv” é chamada de Protected Interoperable File Format (PIFF) (GHOSH; CAMERON, 2010). Além dos arquivos de vídeo em codificações diferentes, também pode ser gerado um ou mais arquivos com a extenção “.isma”. Esse arquivo, codificado semelhantemente ao “.ismv”, contém o áudio referente ao vídeo em questão, ou ainda pode existir somente os arquivos “.isma” caso o conteúdo a ser utilizado seja somente áudio. Estes arquivos de vídeo para a utilização do streaming utilizando Smooth Streaming são codificados utilizando MPEG-4 Part 14, também conhecido por MP4 (TABORDA, 2010). Juntamente com estes arquivos, é gerado um arquivo “.ism”, chamado de arquivo “manifest” do servidor e em seu conteúdo é armazenado o mapeamento de cada arquivo ISMV e ISMA, seus níveis de qualidade e taxas de bits. Este arquivo é utilizado pelo servidor para acessar o fragmento específico no arquivo em disco quando requisitado pelo cliente. Neste arquivo ISM também contém armazenado o caminho de um arquivo “manifest” utilizado pelo player cliente, o qual recebe a extenção “.ismc”. Este arquivo possui todas as informações necessárias para que o player cliente possa reproduzir o conteúdo de forma adequada, como por exemplo informações sobre os níveis de qualidade disponíveis, informações de tempo de cada fragmento, metadados, entre outras informações. Logo após o player cliente receber o arquivo “manifest” ISMC, ele faz a leitura e inicia as requisições de cada fragmento da mídia, sequen-

30

cialmente conforme os dados armazenados no arquivo “manifest” (GHOSH; CAMERON, 2010; AKHSHABI; BEGEN; DOVROLIS, 2011). Apesar de o Microsoft IIS Smooth Streaming ser gratuito, para a sua utilização é necessário um servidor com sistema operacional Windows, e para distribuição de vídeos ao vivo, requisita especificamente do Expression Encoder e ambos requerem a compra de licenças específicas (GHOSH; CAMERON, 2010, p. 949-951). No entanto, existem módulos capazes de possibilitar a outros aplicativos que utilizam distribuição HTTP, como Apache5 , a servidor HTTP Smooth Streaming. Como o pré-requisito para este trabalho é a utilização de tecnologias e ferramentas que proporcionem o desenvolvimento de um produto com conceito de código aberto e baixo custo para implantação, optou-se por descartar o Microsoft IIS Smooth Streaming pelo necessidade de possuir licenças específicas para utilizá-la em seu ambiente, ou em outros casos a necessidade de instalação de módulos não triviais para complementar o servidor web a fim de tornar o servidor web capaz de servir tal tecnologia.

2.2.0.2

Adobe HTTP Dynamic Streaming O Adobe HTTP Dynamic Streaming, assim como o Microsoft Smooth Streaming também

é uma adaptação, desenvolvida pela empresa Adobe, para transportar streaming sob conexões HTTP ao vivo ou sob demanda. Da mesma maneira, o HTTP Dynamic Streaming utiliza o MPEG-4 Part 12 como base para o formato estendido que o utiliza para distribuição de conteúdo, o formato F4V, gerando arquivos com a extensão “.f4f” (ADOBE, 2010). Segundo Adobe (2010), os fragmentos F4F, e também MP4 que é extendido do MPEG-4 Part 12, são utilizados tanto para streaming ao vivo e sob demanda com suporte total para a CODECs de alta qualidade de mídia disponíveis na Plataforma Adobe Flash. Pode-se afirmar então que, para a utilização do HTTP Dynamic Streaming como tecnologia de streaming, é necessário que o player cliente seja desenvolvido em plataforma Adobe Flash, comumente chamada de Flash Player. Esta restrição torna-se um empasse quando se analisa a atual era tecnológica, percebendo que nem todos os dispositivos capazes de serem utilizados para streaming de vídeo suportam ou possibilitam a instalação de Flash Player. Um exemplo desta afirmação é o dispositivo tablet iPad da empresa Apple (SAMPAIO, 2011, p. 38). O HTTP Dynamic Streaming utiliza exclusivamente MP4 ou VP6 como CODECs de compressão de dados em alta qualidade e que também são compatíveis com a plataforma Adobe Flash. E assim como o Microsoft Smooth Streaming, também possui um aplicativo que realiza a codificação dos vídeos originais, o preparando para o distribuir posteriormente. Adobe
5

http://h264.code-shop.com/trac/wiki/Mod-Smooth-Streaming-Apache-Version1

31

desenvolveu um aplicativo para a preparação dos vídeos previamente gravados e para a distribuição em demanda, o qual é chamado de File Packager, e para streaming em tempo real, um aplicativo com nome de Live Packager (ADOBE, 2010). Para a distribuição de conteúdo, pode ser utilizado usando o software de servidor web Apache padrão e infraestruturas de cache. A fim de facilitar a implantação, a Adobe disponibiliza um módulo6 adicional ao Apache que pode ser instalado no servidor para ser usado na distribuição do HTTP Dynamic Streaming (ADOBE, 2011). O aplicativo codificador para vídeo previamente gravado é disponibilizado gratuitamente pela empresa desenvolvedora, e apenas o aplicativo codificador para a versão de distribuição em tempo real requer uma licença que é vendida separadamente pela empresa distribuidora. Durante a preparação do arquivo de vídeo para a preparação no formato de distribuição sob demanda, quando utilizado o HTTP Dynamic Streaming, são gerados dois arquivos. Um arquivo possui a extensão F4F que possui todos os fragmentos MP4 compilados. Um segundo arquivo recebe a extensão F4M, e nele existem textos baseados em um arquivo Extensible Markup Language(XML) formando o arquivo manifest, contendo informações de inicialização, informações de taxa de bits, metadados de informações de licença do servidor utilizado, entre outras informações (ADOBE, 2010). Como essa seção aborda tecnologias de streaming adaptativos, assim como o Microsoft Smooth Streaming, o HTTP Dynamic Streaming também pode utilizar mais arquivos de vídeo codificados com taxas de bits diferentes para a adaptação. No entanto, como relembra Adobe (2010), algumas considerações devem ser feitas para garantir uma reprodução adequada para o telespectador. O autor enuncia que uma das considerações importantes é a perfeita sincronização dos keyframes também chamados de quadros-chave, que são utilizados como um guia a fim de determinar o início e o fim dos fragmentos do arquivo. Isto porque como o Microsoft Smooth Streaming, ao utilizar o HTTP Dynamic Streaming, o servidor de mídia cria fragmentos virtuais de acordo com os keyframes. Como o Flash Player muda o tempo de reprodução do player de acordo com os keyframes, caso todos os keyframes entre os arquivos codificados com taxas de bits diferentes estejam alinhados, a troca do arquivo na adaptação de taxa de bits torna-se imperceptível ao telespectador (ADOBE, 2010). Para a distribuição em tempo real, às ferramentas disponíveis funcionam semelhantemente ao modo de distribuição sob demanda. A Adobe disponibiliza uma ferramenta chamada de Live Packager que converte as entradas ao vivo em formato de transmissão Real-Time Messaging Protocol (RTMP), que é um protocolo proprietário da Adobe, o qual é muito parecido com o RTSP (PFEIFFER, 2010). Para tal, é utilizado como servidor de distribuição compatível
6

http://www.adobe.com/go/httpdynamicstreaming_bits

32

chamado de Flash Media Server que também é um software proprietário da Adobe. Porém ainda existem ferramentas open source como, por exemplo, o Red5. Todavia, para a utilização do Red5 é necessário que o servidor web possua, instalado em seu sistema operacional, o Java (PFEIFFER, 2010). Como citado anteriormente, o player capaz de reproduzir HTTP Dynamic Streaming é desenvolvido utilizando tecnologia Adobe Flash. Justamente por ser necessário esta tecnologia proprietária, a Adobe aproveitou para criar módulos específicos dentro da sua tecnologia Flash a favor de aumentar significativamente a interação avançada entre o player cliente e o servidor de distribuição de mídia. Para possibilitar a disseminação do uso de sua tecnologia, a Adobe desenvolveu um framework gratuito de código aberto, desenlvolvido utilizando ActionScript 3.0 o qual recebeu o nome de Open Source Media Framework 7 (OSMF). Este framework possibilita aos desenvolvedores criarem player de mídia personalizados, capaz de integrar outras extensões desenvolvidas por terceiros, e com total suporte a HTTP Dynamic Streaming. Um player desenvolvido utilizando OSMF suporta tanto o streaming por HTTP como também streaming por RTMP (ADOBE, 2010). Com a utilização do OSMF Player, é possível monitorar o ambiente onde o dispositivo cliente está inserido e, de acordo com as alterações nesse ambiente, escolher qual taxa de bits deve requisitar ao servidor de mídia, para que possa proporcionar a melhor experiência possível ao usuário. Apesar da possibilidade de ser implantando utilizando as ferramentas gratuitas disponíveis, o HTTP Dynamic Streaming requer modificações no sistema operacional do servidor, de modo que estas modificações não sejam triviais para as configurações de um servidor web. Além disso, há necessidade de utilização de Flash Player como plugin proprietário para a utilização desta solução, o que cria um ponto negativo em sua análise de implementação, relembrando ainda que existem dispositivos que não possuem possibilidade de instalação deste plugin em seu sistema operacional. Observa-se nitidamente que a utilização desta solução de streaming adaptativo não satisfaz os requisitos impostos para este trabalho.

2.2.0.3

Apple HTTP Live Streaming Desenvolvido pela Apple, HTTP Live Streaming, ou simplesmente chamado pelas ini-

ciais HLS, é entre as três extensões citadas a mais jovem e com possibilidades de ser aceito como um padrão ao se analisar suas propriedades e o ambiente em que está sendo desenvol7 Mais detalhes sobre Open Source Media Framework estão disponíveis no endereço eletrônico: http://opensourcemediaframework.com/

33

vida. A abordagem dele é amplamente especificada em um draft8 para RFC, tendo uma boa evolução desde sua primeira versão em maio de 2009 até a sétima publicação em setembro de 2011 (atual versão a qual foi utilizada para captação e exploração das informações sobre o tema). Dentre as três extensões do HTTP Streaming adaptativo citadas até então, esta é a única que possui sua proposta aberta em uma publicação, descrevendo todo o seu funcionamento, acessível a qualquer indivíduo. Desde a primeira versão do draft, que descrevia a versão 1 desta extensão, em que o draft o descreve como um protocolo para transmissão de streaming ilimitado de mídia sobre HTTP, várias melhorias foram implementadas, mas seu conceito ainda permanece o mesmo: especificar o formato dos dados dos arquivos e as ações que o servidor deve tomar e como o player cliente deve agir. A versão mais atual cita que a versão utilizada do protocolo é a versão 4 (PANTOS, 2011). O HLS é parecido com o funcionamento das outras extensões anteriormente citadas, porém possui aspectos e propriedades específicas encontradas somente nele. Pode-se citar a forma de armazenamento dos fragmentos de mídia, a forma de distribuição, o método de execução e a tecnologia utilizada para o desenvolvimento do Player cliente. Ao contrário do HTTP Dynamic Streaming e Microsoft Smooth Streaming, que criam fragmentos virtuais que estão salvos em um único arquivo convertido em uma taxa de bits específicos, o HTTP Streaming utiliza fragmentos físicos, separados e armazenados no servidor de distribuição (PANTOS, 2011). Estes fragmentos são gerados a partir do componente servidor, utilizando como entrada o vídeo original, e recebendo os parâmetros específicos para configuração e geração dos fragmentos ao mesmo tempo em que altera a taxa de bits, também especificada nos parâmetros. Para fins de entendimento, será atribuido neste trabalho ao componente servidor, o nome de Segmentador de HLS. O trabalho do Segmentador de HLS, normalmente um software aplicativo, é basicamente ler o fluxo de entrada ou um arquivo físico previamente gravado, codificá-lo e dividi-lo em uma série de pequenos arquivos de mídia de igual duração de tempo. Estes pequenos pedaços normalmente são encapsulados com fluxo de transporte MPEG-2. Este formato suporta uma grande variedade de formatos de compressão de áudio e vídeo (APPLE, 2011). Os fragmentos gerados normalmente são fragmentos iguais de 10 segundos, os quais recebem como extensão “.ts”, abreviação de “MPEG transport stream” que é especificado no MPEG-2. Nas outras extensões de HTTP adaptativo citadas anteriormente, era gerado um arquivo chamado de “manifest” o qual possuía informações sobre os arquivos disponíveis para a adaptação bem como informações necessárias para a utilização do método adaptativo. No HTTP
8 Um rascunho, pode ser uma apresentação individual ou uma apresentação do grupo de trabalho. Quando um rascunho é considerado maduro por um grupo de trabalho se torna uma RFC (ZAPATA, 2006)

34

Live Streaming, apesar de utilizar uma forma diferente de armazenamento, também possui um arquivo “manifest” que é gerado a partir do Segmentador de HLS e é comumente chamado de arquivo de índice. Este arquivo contém referências dos arquivos, segmentos de mídia, gerados e é salvo em formato de lista de reprodução (playlist) M3U8 (PANTOS, 2011). O arquivo M3U8 consiste em um arquivo de texto simples, contendo nele um ou diversos endereços dos arquivos fragmentados sequencialmente, endereço este que recebe o nome de Uniform Resource Locator (URL), além de tags específicas, utilizadas como parâmetros e informações pelo player cliente. O Segmentador de HLS não necessariamente deve estar no mesmo servidor de distribuição. Ele pode estar em qualquer hospedeiro que possua suporte para realizar as atividades. A Apple disponibiliza várias ferramentas para gerar os arquivos necessários para HTTP Live Streaming. O streaming “ao vivo” e “sob demanda” no HTTP Live Streaming trabalham de forma parecida. O método de streaming ao vivo utilizando o HTTP Live Streaming possui características particulares e bem diferentes do mesmo método em seus concorrentes. Como descrito no parágrafo anterior, não é necessário que o segmentador de HLS esteja no mesmo hospedeiro que o servidor de distribuição, este último pode ser qualquer servidor web que sirva os arquivos requisitados sobre conexões HTTP. Isso porque o projeto do HLS, assim como a proposta deste trabalho, requerer mínimas mudanças na infraestrutura do servidor de distribuição. São vários os softwares que podem ser utilizados como servidores web cache para distribuição de HTTP Live streaming. Entre eles pode-se encontrar Microsoft IIS para servidores Windows, e também Apache para servidores Linux. Atualmente a versão estável do Apache já inclui como padrão em seu arquivo de configuração9 de MIME types a especificação para arquivos .M3U8. Então, infere-se que pelo fato do papel do servidor de distribuição ser apenas aceitar as requisições e respondê-las, nenhuma modificação nele é necessária para a utilização do HTTP Live Streaming. Isso é um ponto positivo ao comparar com o propósito deste trabalho. Há de se citar, também, que diferente das outras extensões citadas anteriormente neste capítulo, o player utilizado para o HTTP Live Streaming não utiliza nenhum framework ou plugin proprietário para a execução do conteúdo audiovisual. Nesse sentido, faz-se apropriada a definição de que, pelo fato de como o protocolo está sendo desenvolvido e o seu funcionamento aberto ao público devido ao acesso do draft da RFC, diversos players podem ser desenvolvidos utilizando qualquer tecnologia que possua linguagem de programação disponível, e que essa seja capaz interagir com requisições HTTP e incorporar reprodução de vídeo em seu conteúdo.
9 Arquivo que faz parte do pacote de instalação do Apache versão 2.3.15. Visualização disponível na URL: http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types

35

Apple (2011) afirma que o HLS está em funcionamento para os dispositivos que possuem o sistema operacional iOS10 versão 3.0 ou maior e em computadores com sistema operacional Mac OS X ou superior. O autor descreve ainda que o navegador web Safari possui, nativamente em seu código, a interpretação de HTTP Live Streaming utilizando tag <video> que faz parte nativamente do HyperText Markup Language (HTML), na versão mais atual em desenvolvimento - o HTML5 (PFEIFFER, 2010). O HTML5, já presente nos navegadores mais atuais, é uma atualização da atual versão HTML suportada pela maioria dos navegadores e, possui novos recursos que anteriormente eram possíveis somente por meio de outras tecnologias incorporadas. Pfeiffer (2010) cita ainda que, no desenvolvimento do HTML5, uma das principais especificações sobre a tag <video> é a interoperabilidade entre CODECs. Neste âmbito, o autor ainda continua, citando que a World Wide Web Consortium (W3C), que é órgão que publica os padrões do HTML, procura publicar somente recomendações que podem ser implementadas sem o uso de código proprietário (royalty-free). Ainda, pode-se citar que a diversificação dos navegadores web, fez com que cada um desses apoia-se um ou mais CODECs específicos de acordo com seus interesses, e da mesma forma deixar de dar suporte a outros. Neste sentido, atualmente a tag <video> é capaz de suportar mais de um codec de vídeo diferente, possibilitando que um código HTML seja lido perfeitamente em vários navegadores atuais, utilizando o arquivo de vídeo alternativo suportado pelo navegador (PFEIFFER, 2010). Ainda nesta perspectiva, Pfeiffer (2010) descreve que existem diferentes formatos de encapsulamento de vídeos disponíveis atualmente, e estes formatos, em sua maioria suportam uma grande quantidade de CODECs de áudio e vídeo com suporte a taxa de bits variáveis, facilitando ainda mais a possibilidade destes serem utilizados para HTTP live Streaming. Mais detalhes sobre CODECs serão abordados no próximo capítulo. Pode ser visto, na figura 6, um exemplo de um código HTML5 exemplificando a implementação de arquivos alternativos de um mesmo vídeo. Apesar de atualmente apenas o navegador web Safari possuir suporte nativo ao HTTP Live Streaming utilizando a tag <video>, e que o HTTP Live Streaming não fazer parte da especificação do HTML5, ainda que se beneficie dela, é lícito supor que a possibilidade desse suporte se estender entre outros navegadores é nitidamente provável. Essa afirmação ainda é influênciada ao relembrar que a especificação do funcionamento do HLS é aberta e ao vermos sua implementação estar presente em uma das versões mais atuais de outro sistema operacional para dispositivos móveis, o Android 3.011 (PFEIFFER, 2010) (KOMATINENI et al., 2011). Ao analisar as informações ditas acima, pode-se notar que o HTTP Live Streaming possui um grande potencial, além de estar alinhado com as expectativas propostas neste trabalho.
10 11

Sistema operacional para dispositivos móveis desenvolvido pela Apple Sistema operacional para dispositivos móveis desenvolvido pela Google

36

1 2 3 4 5 6 7 8 9 10 11

< !DOCTYPE html> <head> < t i t l e >Exemplo de HTML5 Vídeo com a r q u i v o s a l t e r n a t i v o s < / t i t l e > <meta h t t p −e q u i v ="Content-Type" content="text/html;charset=utf-8" / > < / head> <body> <video c o n t r o l s > <source src="video.mp4" type="video/mp4" / > <source src="video.webm" type="video/webm" / > < / video> < / body>

Figura 6: Exemplo de um código fonte HTML5 com elemento <video>
Fonte: adaptado de Powers (2011, p. 10)

Da mesma forma que existem interesses pessoais na utilização de novas tecnologias, como o HTML5, pode-se dizer que HTTP Live Streaming é uma tecnologia emergente, que propicia a implementação do aprendizado em matérias do curso ao qual está sendo validado os conhecimentos no presente trabalho. Portanto, o HTTP Live Streaming foi escolhido como tecnologia a ser utilizada no desenvolvimento desta pesquisa.

2.3

CODECS E CONTÊINER PARA VÍDEO STREAMING ADAPTATIVO A palavra CODEC, citada diversas vezes neste trabalho, refere-se a um elemento de

extrema importância na área de áudio e vídeo para web. Nesta sessão, serão abordados alguns CODECs utilizados na distribuição de vídeo em formato streaming adaptativo. Antes disso, porém, é necessário que se proceda a definição e funcionamento de um CODEC bem como tornar clara a diferenciação entre CODECs e contêiner de vídeo. Quando se está trabalhando com arquivos de mídia, esses são compostos por dois componentes separados: o CODEC, que é a abreviação união das palavras inglesas compressordecompressor (COmpressor-DECompressor) e é o responsável por codificar e decodificar o fluxo de áudio e/ou vídeo, e o contêiner, que é considerado uma embalagem da mídia, composto pelos fluxos de mídia, informações sobre os dados e, em alguns casos, metadados. Contêineres de vídeo podem suportar, além dos fluxos de mídia, subtítulos, legendas e ainda outras informações necessárias para a execução e sincronia dos dados (POWERS, 2011). Segundo Powers (2011), o contêiner de vídeo é capaz de envolver vários CODECs diferentes. O autor cita como exemplo, o contêiner de código aberto Ogg e também o CODEC de código aberto VP8, o qual foi adquirido pela empresa Google em fevereiro de 2010 (PFEIFFER, 2010). Pfeiffer (2010), relaciona alguns exemplos de contêineres que podem ser utilizados em streaming adaptativos por possuírem a capacidade de lidar com taxa de bits variáveis, entre

37

eles: MPEG MP4, Matroska MKV (este servindo como base para o desenvolvimento do formato WebM), e Xiph Ogg. Igualmente, Pfeiffer (2010) afirma que são inúmeros os CODECs existentes atualmente, e também relembra que existem CODECs específicos para áudio e vídeo, os quais podem ser combinados durante a criação do arquivo de mídia. Embora seja possível a utilização de vários CODECs em um contêiner, normalmente são encontrados apenas alguns CODECs específicos em determinados contêineres (PFEIFFER, 2010). Como as especificações do HTML5 ainda estão sendo desenvolvidas, não se chegou a escolha de um “CODEC base”, para ser apontado pela comissão do W3C, a fim de padronizar e tornar possível trabalhar com um único CODEC, sabendo que esse será suportado em todos os navegadores (PFEIFFER, 2010). Pfeiffer (2010) afirma que uma boa escolha na especificação do “CODEC base” é muito importante para manter a interoperabilidade, e com isso melhorar a experiência do usuário final. Afirmou-se, anteriormente, que a diversificação dos navegadores web, fez com que cada um desses apoie-se em um ou mais CODECs específicos de acordo com seus interesses. Porém, algumas dessas escolhas vai contra o princípio fundamental do HTML5, que é utilizar somente componentes que possam ser implementados sem o uso de código proprietário. Um exemplo disso é o CODEC H.264, o qual foi escolhido pela Microsoft como CODEC principal no suporte a HTML5 em seu navegador, o Internet Explorer. Pelo fato de que, para a utilização do H.264, é necessário ser pago direitos de royalties, a Google, por sua vez, decidiu por não dar suporte a este CODEC nas versões do seu navegador web, o Chrome. Da mesma forma, o CODEC VP8 que é normalmente utilizado no contêiner WebM, foi escolhido pela Google para ser o padrão para seu navegador web, porém não possui suporte no navegador da Microsoft (PFEIFFER, 2010; POWERS, 2011). No quadro 2 é exibido um sumário da situação do suporte nativo de alguns dos principais navegadores web. Quadro 2: Introdução do suporte de vídeo para HTML5 nos principais navegadores web

Fonte: adaptado de Pfeiffer (2010, p. 6)

O MPEG-4 Part 10, frequentemente chamado de H.264, foi escolhido pela Microsoft e Apple como padrão para seus navegadores Internet Explorer e Safari. O H.264 é um CODEC maduro, trabalhando com compressão de vídeo de alta qualidade, que se tornou popular na

38

Internet, sendo suportado pelo site de compartilhamento de vídeo YouTube, iTunes e também um dos CODECs obrigatórios em players Blue-Rays (POWERS, 2011). Powers (2011) relembra que, apesar dos arquivos codificados em H.264 serem distribuídos sem custo, as ferramentas utilizadas para codificar e decodificar devem pagar royalties. O autor cita ainda que, por este motivo, Google, Mozilla e Opera deixaram de dar suporte ao H.264. A MPEG LA, líder mundial em licenças tecnológicas alternativas e atual detentora dos direitos de royalties do H.264, informou em fevereiro de 2010 uma nota anunciando que em 2016, tornará livre a utilização H.264, fornecendo acesso aos seus direitos de patente (O’REILLY, 2010). Mesmo com essa afirmação, não é lícito supor que no futuro os papéis se inverterão, e o H.264 será o padrão oficial para distribuição de vídeo apontado pela W3C, de modo que, outros CODECs estão sendo desenvolvidos e aperfeiçoados e podem se tornar populares até a data especificada pela MPEG LA. Um destes seria o VP8, apoiado pelo contêiner WebM, criado primeiramente pela empresa On2 e comprado posteriormente pela Google, que prontamente o liberou como um CODEC de código aberto, livre de cobrança de royalties. Inúmeras são as brigas em tribunais e diferenças entre aplicações pelo motivo de direitos de royalties sobre os CODECs (POWERS, 2011). De acordo com Pfeiffer (2010), com a intenção da Google em liberar o VP8/WebM para uso livre de royalties, empresas como Opera, Mozilla, Adobe, entre muitas outras, sentiramse estimuladas a adotarem esse CODEC como padrão para suas aplicações, visto que o VP8 está muito próximo, em termos de qualidade de vídeo, do H.264 e, por isso, possui grandes chances de ser escolhido para ser o CODEC Base para HTML5. Ainda nesta perspectiva, Pfeiffer (2010) afirma que a Google, aos poucos, está conseguindo encorajar outros sites de publicações de vídeo a utilizarem o WebM/VP8. Alguns dos endereços desses sites podem ser vistos no quadro 3. Outra peculiaridade que pode-se apontar sobre os CODECs de vídeo, é que eles podem codificar a mídia com perda (lossy ) e sem perda(lossless). CODECs sem perda preservam todos os dados originais do arquivo após o seu empacotamento. Ao contrário dos CODECs com perda, que utilizam técnicas de compressão com a finalidade de minimizar a quantidade de dados a serem armazenados ou transmitidos pelo computador, isto é, diminuir o tamanho do arquivo físico a ser armazenado ou diminuir o consumo de banda necessária para transmiti-lo (POWERS, 2011). No entanto, Powers (2011) aponta que, somente CODECs com perda são suportados para vídeos HTML5. Acredita-se, face ao que foi exposto, que os CODECs que melhor se aplicam a este estudo, são os desenvolvidos com o princípio de código aberto e livres de royalties, como por exemplo, VP8 e Ogg Theora. Porém, Pfeiffer (2010) informa que atualmente, somente O CO-

39

Quadro 3: Suporte de vídeo HTML5 em alguns sites de vídeo de grandes publicações (social e comercial)

Quadro adaptado de Pfeiffer (2010, p. 6)

DEC de vídeo H.264 possui suporte para este tipo de conteúdo audiovisual. Portanto, para possibilitar a compressão de vídeo, sem a necessidade de pagamento de royalties, optou-se pela utilização da biblioteca de compressão X.264. A biblioteca X.264, com uma comunidade ativa e inovadora de desenvolvedores, é um implementação open source de um codificador H.264 e, por isso, utilizado em uma variedade de produtos não comerciais (PFEIFFER, 2010) (WAGGONER, 2009).

40

3

HTTP LIVE STREAMING

Como descrito no capítulo anterior, escolheu-se o HTTP Live Streaming pelo fato de ser uma das tecnologias que utilizam HTTP Streaming que está em conformidades com este trabalho, e possuir a documentação, embora essa ainda encontra-se em andamento. Além disso, essa tecnologia se beneficia das inovações que estão sendo geradas com o novo padrão de HTML, seja para ambientes desktops, seja para dispositivos móveis. O HTTP Live Streaming foi inicialmente desenvolvido pela Apple para permitir que provedores de conteúdos diversos pudessem enviar conteúdos audiovisuais para dispositivos por ela desenvolvidos, como, por exemplo, iPhone e iPod. Após isso, eles desenvolveram a mesma funcionalidade em seu player desktop, o QuickTime, e iniciou-se o desenvolvimento da documentação, enviada então para a IETF para se tornar um padrão de streaming sobre HTTP. Atualmente o HLS possui suporte nativo apenas em dispositivos móveis que utilizam o sistema operacional iOS 3.0 ou superior, e no navegador web Safari utilizando o sistema operacional MAC OS X (APPLE, 2011). Porém, pelo fato de ser uma documentação aberta, novos aplicativos estão sendo desenvolvidos tornando possível a utilização do HLS em outros dispositivos, em especial os que possuem sistema operacional Android 3.0 ou superior, que já possuem nativamente suporte ao HTTP Live Streaming (KOMATINENI et al., 2011). Para implementar HTTP Live Streaming, é necessário criar uma página HTML, nos moldes do HTML5, ou ainda um aplicativo cliente para atuar como receptor dos dados de mídia. Além disso, é necessário o uso de um servidor web para armazenar os fragmentos de mídia e arquivos “manifest”, bem como um receptor da mídia original para servir como codificador, gerando os fragmentos de mídia. A fim de aprofundar-se no tema, é necessário entender do escopo de seu funcionamento. Apple (2011, p. 11) afirma que, conceitualmente, o HTTP Live Streaming consiste em três partes: a) componente servidor: software responsável por receber a mídia original, codificála digitalmente e gerar os fragmentos de mídia em um formato adequado para a entrega; b) componente de distribuição: um servidor web padrão. Trabalha como responsável em aceitar as requisições do player cliente e respondê-las de acordo com o tipo da requisição; c) software Cliente: é o responsável por avaliar os recursos disponíveis no ambiente e determinar a escolha dos arquivos de mídia em sua taxa de bits que melhor se adapte ao cenário atual. Também é sua responsabilidade, após receber o

41

retorno da requisição contendo os arquivos (fragmentos) solicitados, montá-los na ordem correta e apresentá-los ao usuário de uma forma contínua. A figura 7 exibe graficamente, por meio de um fluxograma, os componentes para a entrega de mídia utilizando HTTP Live Streaming.

Figura 7: Fluxograma do funcionamento da entrega de HTTP Live Streaming
Adaptada de Apple (2011, p. 7)

Tem-se assim o ponto de partida para a compreensão a fim de aprofundar-se no funcionamento do HTTP Live Streaming. Para isso, pode iniciar-se pela análise do primeiro ponto da geração do conteúdo para o HTTP Live Streaming, ou seja, pelo componente servidor e a captura da mídia. A mídia utilizada pelo componente servidor pode ser gerada em tempo real, ou ainda ter sido gravada antecipadamente. Para a mídia em tempo real, a Apple disponibiliza uma aplicação denominada Media Stream Segmenter, utilizada via linha de comando. Essa ferramenta é capaz de capturar em, tempo real, um fluxo de mídia contínuo do tipo MPEG-2 e, em seguida, gerar os fragmentos de mídia necessários para o streaming adaptativo, bem como os arquivos playlist dos arquivos. Para a mídia previamente gravada, a Apple disponibiliza outra aplicação denominada Media File Segmenter, que, assim como a aplicação para mídia em tempo real, também é utilizada via linha de comando e gera o mesmo produto final (APPLE, 2011). Antes de continuar com a análise entre as duas formas de utilização do HTTP Live Streaming, faz-se necessárias algumas explicações.

42

Primeiramente pode-se citar os segmentos gerados pelas aplicações que, apesar de não ser uma obrigatoriedade, normalmente possuem a extensão “.ts” (abreviatura de Transport Stream), os quais são fragmentos de igual tamanho de tempo, da mídia original. As URLs relativas de acesso a estes arquivos são inseridas no arquivo playlist, conforme a ordem de criação de cada fragmento. O arquivo playlist, é um arquivo do tipo M3U8, uma extensão do formato de lista de reprodução M3U. Arquivos M3U são arquivos de texto simples, que consistem em linhas individuais e cada linha é uma URL, ou começa com um símbolo ASCII “#” (cerquilha) (PANTOS, 2011). Pantos (2011) cita que linhas em branco são ignoradas. O autor também descreve que as linhas iniciadas com o símbolo “#” podem ser comentários ou tags dentro de um arquivo M3U. Neste caso, a citação de tag em uma linha é sempre iniciada com os caracteres “#EXT” e, por se tratarem de tags que podem indicar uma variável ou comando ao player de mídia, é altamente recomendável que não existam espaços em branco nestas tags, exceto para os elementos em que é explicitamente especificado. As demais linhas são consideradas comentários e, portanto são ignoradas. No draft do HTTP Live Streaming, são descritas as novas tags para extensão do arquivo M3U8 as quais são utilizadas exclusivamente no software cliente. Um exemplo de um arquivo playlist de HTTP Live Streaming pode ser visto na figura 8.

1 2 3 4 5 6 7 8 9 10

#EXTM3U #EXT−X−TARGETDURATION: 1 0 #EXT−X−MEDIA− SEQUENCE: 0 #EXTINF : 1 0 , h t t p : / / m i d i a . exemplo . com . b r / segmento0 . t s #EXTINF : 1 0 , h t t p : / / m i d i a . exemplo . com . b r / segmento1 . t s #EXTINF : 1 0 , h t t p : / / m i d i a . exemplo . com . b r / segmento2 . t s #EXT−X−ENDLIST

Figura 8: Exemplo de um arquivo .M3U8 No caso de streaming previamente gravado, o software cliente realiza o download do arquivo playlist, contendo a lista completa de todos os fragmentos e suas URLs, apenas uma vez no início da transmissão. Já para as transmissões ao vivo, o arquivo é atualizado a cada novo fragmento gerado pela aplicação. Neste caso, o cliente faz requisições a cada período de tempo, a fim de obter a lista mais atualizada do arquivo. Um arquivo playlist M3U8 deve iniciar com a tag “#EXTM3U” logo na primeira linha do arquivo. Esta tag é fundamental, pois a partir dela que se diferencia um arquivo M3U do arquivo estendido M3U8. Em seguida, verifica-se na linha 2 a tag “#EXT-X-TARGETDURATION” que é responsável por indicar o tempo máximo em segundos dos fragmentos. Essa tag deve

43

aparecer somente uma vez e se aplica a todo o arquivo da lista de reprodução. O valor de tempo é indicado após a tag, e separado pelo caractere “:” (dois pontos) por um número inteiro positivo. Cada URI em um arquivo playlist contém um numero de sequência única, e este valor é indicado pela tag “#EXT-X-MEDIA-SEQUENCE” e pode ser visualizada na linha 3 da figura 8. A sua inserção não é obrigatória, porém, caso não exista sua declaração no arquivo, seu valor é automaticamente entendido pelo player cliente como valor zero. Essa tag pode existir somente uma vez no arquivo playlist. O número de sequência de cada URI é composto pelo valor da URI anterior acrescida de mais o valor 1 (PANTOS, 2011). Pode-se notar no exemplo da figura 8 a presença da tag “#EXTINF”. Ela especifica a duração em segundos do segmento de mídia que está disposto logo após a sua declaração no arquivo. Esta tag, após a sua declaração, recebe o caractere “:”, e em seguida suas variáveis. A primeira variável é obrigatória, composta de um número positivo, inteiro ou de notação decimal, indicando o tempo em segundos da duração do fragmento. A segunda variável, não obrigatória, indica um título informativo para o segmento. Estas variáveis são separadas por uma vírgula. Nota-se também que a linha 10 possui uma tag específica, indicando o fim do arquivo. A tag “#EXT-X-ENDLIST” indica que nenhuma nova linha, contendo a URL de algum fragmento, será adicionada no final do arquivo. Essa tag não pode aparecer mais de uma vez em um mesmo arquivo playlist (PANTOS, 2011). E no caso de um fluxo de mídia contínuo em tempo real, a cada novo fragmento gerado, a aplicação deve atualizar o arquivo playlist e somente no final da transmissão inserir a tag indicando a sua finalização. Neste âmbito, caso o segmentador não esteja no mesmo servidor de distribuição, após as alterações feitas e os segmentos gerados, esses devem ser enviados ao servidor de distribuição, utilizando o método comumente conhecido como upload, a fim de disponibilizar posteriormente os dados acessíveis aos clientes. Consequentemente este processo gera uma latência, que consiste em uma diferença de tempo entre o acontecimento ao vivo e o tempo em que o cliente está visualizando o conteúdo gravado sendo distribuído. Apple (2011) cita ainda que a latência típica e recomendada é de aproximadamente 30 segundos. A partir dessa afirmação, faz-se apropriada a recomendação de utilizar o segmentador de HLS em um dispositivo com acesso a uma rede mais ampla para a conexão entre ele e o servidor de distribuição, com o intuito de sofrer mínimas oscilações e proporcionar um fluxo constante no streaming ao vivo (APPLE, 2011). Inúmeros outros exemplos de tags poderiam ser citados aqui, porém, com apenas essas tags citadas é possível utilizar e verificar o funcionamento de um streaming utilizando o HLS. Ainda sobre a existência do arquivo playlist, relembra-se da questão de streaming adaptativo. Para o funcionamento da adaptação da mídia, existe a possibilidade da criação de um

44

arquivo de índice mestre, listando nele outros arquivos playlist alternativos com os fragmentos codificados em taxa de bits diferentes. Para a geração deste arquivo de índice mestre, Apple também disponibiliza uma aplicação de linha de comando, denominada Variant Playlist Creator, capaz de produzir o arquivo de acordo com os parâmetros utilizados (APPLE, 2011). Pode-se visualizar na figura 9 um exemplo de um arquivo de índice mestre.

1 2 3 4 5 6 7

#EXTM3U #EXT−X− STREAM INF :PROGRAM ID =1 ,BANDWIDTH=1280000 − − h t t p : / / m i d i a . exemplo . com . b r / b a i x a _ q u a l i d a d e . m3u8 #EXT−X− STREAM INF :PROGRAM ID =1 ,BANDWIDTH=2560000 − − h t t p : / / m i d i a . exemplo . com . b r / media_qualidade . m3u8 #EXT−X− STREAM INF :PROGRAM ID =1 ,BANDWIDTH=7680000 − − h t t p : / / m i d i a . exemplo . com . b r / a l t a _ q u a l i d a d e . m3u8

Figura 9: Exemplo de um arquivo .M3U8 com variações de taxa de bits Igualmente, a figura 10 exibe graficamente o arquivo de índice mestre apontando para os arquivos playlist alternativos, e esses por sua vez, apontando para os fragmentos de mídia.

Figura 10: Exemplo gráfico de arquivos de índice alternativos
Adaptada de Apple (2011, p. 20)

Pode-se visualizar na figura 9 a tag “#EXT-X-STREAM-INF”. Essa tag é responsável por identificar uma URI como um arquivo playlist e fornecer informações para a sua correta interpretação pelo player cliente. Ela é escrita na linha que antecede a URI do arquivo playlist, e seu valor é composto por parâmetros e valores específicos que podem ser visualizados no quadro 4. Seu formato de utilização é da seguinte maneira: “#EXT-X-STREAM-INF:<lista de atributos separados por vírgulas>” (PANTOS, 2011).

45

Quadro 4: Atributos de identificação de URI para tag #EXT-X-STREAM-INF Atributo BANDWIDTH Valor Aceita como valor um número inteiro positivo, indicando a maior taxa de bits por segundo dos fragmentos da playlist. Este valor é obrigatório para esta tag. Deve ser um limite superior a taxa de bits dos fragmentos a fim de evitar overhead. É um inteiro que identifica a apresentação dentro do escopo de cada playlist. Este valor pode-se repetir a fim de identificar playlists com diferentes codificações de taxa de bits. Sua presença não é obrigatória. Contém valores, envolvidos por aspas (“”) e separados por vírgulas, de nomes de CODECs de mídia descritos de acordo com a ISO. Este parâmetro deve ser incluído nas declarações de #EXT-X-STREAM-INF. Indica um valor aproximado da resolução horizontal e vertical do vídeo presente no arquivo playlist. Sua declaração é escrita por dois números inteiros separados pelo caractere “x”, onde o primeiro valor é equivalente a largura e o segundo a altura. Deve corresponder ao valor do parâmetro GRUPO-ID da tag #EXT-X-MEDIA que possui valor “AUDIO” para atributo TYPE, indicando o conjunto de áudio que deve ser utilizado para interpretação no momento da reprodução. Deve corresponder ao valor do parâmetro GRUPO-ID da tag #EXT-X-MEDIA que possui valor “VIDEO” para atributo TYPE, indicando o conjunto de áudio que deve ser utilizado para interpretação no momento da reprodução.
Quadro atapdato de Pantos (2011)

PROGRAM-ID

CODECS

RESOLUTION

AUDIO

VIDEO

Os arquivos de índice são normalmente criados pelo segmentador disponível pela Apple, porém, é possível utilizar segmentadores alternativos para a criação dos fragmentos e arquivos de índice, desde que esses cumpram com as especificações do HLS. Por exemplo, para a criação de um arquivo playlist pode ser utilizado um simples editor de texto, listando os fragmentos da série de mídia (APPLE, 2011). Além da possibilidade de existir arquivos de índice alternativos para diferentes larguras de banda, é possível também existir arquivos de índice paralelos em caso de haver falha no arquivo de índice como, por exemplo, uma resposta negativa do servidor web, assim possibilitando que o player obtenha os fragmentos de um servidor de backup, dando continuidade a reprodução da mídia. O nome dado a essa propriedade de criar arquivos de índice paralelos em caso de falhas é “Proteção Failover ”. A figura 11 exemplifica um arquivo de índice com as URIs alternativas paralelas, indicando um segundo subdomínio.

46

1 3 4 5 6 8 9 10 11

#EXTM3U #EXT−X− STREAM INF :PROGRAM ID =1 ,BANDWIDTH=1280000 − − h t t p : / / m i d i a . exemplo . com . b r / b a i x a _ q u a l i d a d e . m3u8 #EXT−X− STREAM INF :PROGRAM ID =1 ,BANDWIDTH=1280000 − − h t t p : / / midia_backup . exemplo . com . b r / b a i x a _ q u a l i d a d e . m3u8 #EXT−X− STREAM INF :PROGRAM ID =1 ,BANDWIDTH=2560000 − − h t t p : / / m i d i a . exemplo . com . b r / media_qualidade . m3u8 #EXT−X− STREAM INF :PROGRAM ID =1 ,BANDWIDTH=2560000 − − h t t p : / / midia_backup . exemplo . com . b r / media_qualidade . m3u8

14 15 16 17

#EXT−X− STREAM INF :PROGRAM ID =1 ,BANDWIDTH=7680000 − − h t t p : / / m i d i a . exemplo . com . b r / a l t a _ q u a l i d a d e . m3u8 #EXT−X− STREAM INF :PROGRAM ID =1 ,BANDWIDTH=7680000 − − h t t p : / / midia_backup . exemplo . com . b r / a l t a _ q u a l i d a d e . m3u8

Figura 11: Exemplo de um arquivo .M3U8 com índices alternativos para Proteção Failover Afirmou-se, anteriormente, que o HTTP Live Streaming requerer mínimas mudanças na infraestrutura do servidor de distribuição. Estendendo essa afirmação, Apple (2011) cita que não faz distinção de servidor web cache, apenas que este deve ser capaz de aceitar as requisições vindas do cliente e respondê-las com o arquivo correto. Em relação a afirmação de que mínimas mudanças são necessárias, o autor cita que a configuração recomendada e que faz parte destas mínimas mudanças, é a especificação do tipo de MIME type, configurado no servidor web, associado aos arquivos .M3U8 e .ts. No quadro 5 é possível verificar essas espeficações. Quadro 5: MIME type específico para cada extensão de arquivo Extensão do Arquivo .M3U8 .ts MIME type application/x-mpegURL video/MP2T

Quadro atapdato de Apple (2011, p. 14)

Para servidores que utilizam Apache, caso seja possível a utilização de arquivos de configuração a nível de diretório, que permitem um gerenciamento descentralizado das configurações do servidor web, o qual normalmente recebe o nome de “.htaccess”, a configuração de MIME type não requer mudanças nos arquivos de configurações padrões, bastando apenas adicionar as linhas específicas no arquivo “.htaccess” que fica geralmente na pasta raiz da URL a ser utilizada na distribuição dos arquivos para HTTP Live Streaming (BRYANT, 2006). Pode-se verificar um exemplo de configuração do arquivo “.htaccess” na figura 12. Esclarecido esse aspecto, entra-se então na questão do armazenamento dos fragmentos de mídia gerados pelo segmentador de HLS. A organização destes arquivos pode ser reali-

47

1 2

AddType a p p l i c a t i o n / x−mpegURL m3u8 AddType v i d e o / MP2T t s

Figura 12: Fragmento de uma arquivo “.htaccess” com as linhas de configuração para HTTP Live Streaming zada armazenando-os em pastas separadas, de forma a facilitar as manipulações dos arquivos por um indivíduo humano, quando necessário. Pois como comentado até então, relembrando que como se trata de streaming adaptativo, poderá existir uma série de outros fragmentos codificados em taxa de bits diferentes, o que pode, em determinado momento, tornar confusa a manipulação destes arquivos caso não seja realizado uma organização coerente dentro do servidor de distribuição. Kurose e Ross (2010) enfatizam que as aplicações de multimídia são sensíveis a atrasos e a perda de tolerância, uma característica diferente para a abordagem de conteúdo estático, como imagens e arquivos de texto, por exemplo. Neste sentido, vale ressaltar que o HTTP Live Streaming utiliza-se de conteúdo estático, visto que seus arquivos estão previamente salvos no servidor de distribuição. E entendendo este aspecto, ressalta-se também a possibilidade de utilizar uma infraestrutura de distribuição melhorada com o intuito de superar possíveis obstáculos para a entrega dos arquivos de mídia. Infraestrutura esta que, pode ser composta por nós de Content Delivery Network (CDN) que estão localizados próximos aos pontos onde se encontram os usuários finais. Acredita-se que com essas descrições dos itens principais que compõem o HTTP Live Streaming, podem-se entender as necessidades básicas para criar um conjunto de arquivos e configurações capazes de possibilitar a utilização do HLS. Frente a isso, é notório possuir entendimento também de aspectos necessários para a criação da mídia original até a sua segmentação, que de acordo com a premissa desta pesquisa é de possibilitar a utilização de HTTP Live Streaming em dispositivos móveis, que possuem pouco poder de processamento e em sua maioria, um limite inferior de largura de banda ao se comparar com os computadores de mesa conectados a redes de alta velocidade. Como citado anteriormente na sessão 2.3, pelo fato da codificação de vídeo utilizada para HTTP Live Streaming ser com perda, o vídeo de entrada deve estar em sua melhor qualidade possível. Portanto, se o vídeo original estiver com uma qualidade considerada baixa, quanto maior a compressão a fim de gerar os fragmentos para dispositivos e redes de baixa capacidade, menor ainda será a qualidade disponível para os usuários destes dispositivos. Esta compressão é basicamente formada pela escolha de alguns fatores como resolução da tela do

48

dispositivo do usuário, número de quadros chaves e taxa de bits, que normalmente são escolhidos com base no público formado pelos usuários finais (APPLE, 2011). Apple (2011) exemplifica algumas combinações de fatores para o vídeo final a ser gerado. Estas combinações podem ser visualizadas no quadro 6. A combinação adequada para o streaming de dados é proporcional a uma boa experiência do usuário. Quadro 6: Exemplos de combinações de fatores para compressão de dados para HLS Conexão Celular Celular Celular Wifi Wifi Wifi Celular Celular Celular Wifi Wifi Resolução de tela 480 x 224 480 x 224 480 x 224 640 x 360 640 x 360 960 x 540 480 x 300 480 x 300 480 x 300 640 x 480 1280 x 960 Taxa de bits 150 kpbs 200 kpbs 440 kpbs 640 kpbs 1024 kpbs 1840 kpbs 150 kpbs 200 kpbs 440 kpbs 640 kpbs 4540 kpbs Keyframes 30 45 90 90 90 90 30 45 90 90 90 Proporção de tela 16:9 16:9 16:9 16:9 16:9 16:9 4:3 4:3 4:3 4:3 4:3

Quadro atapdato de Apple (2011, p. 25-26)

Apple (2011) contínua ainda descrevendo que, independente da velocidade de conexão, é recomendável que exista mais de um arquivo de índice mestre composto por taxas de fluxo de bits variáveis, garantindo assim uma boa experiência ao usuário. O autor ainda indica algumas taxas recomendadas, como 150kbp/s para conexões de celular e 240kbp/s para conexões Wifi, porém vale ressaltar novamente que estes valores podem variar de acordo com o público final que utilizará do streaming de mídia. Ainda nessa perspectiva, afirma-se ainda que a má configuração do arquivo de índice como, a tag BANDWIDTH (verificada no quadro 5) pode fazer com que o vídeo não reproduza suavemente, causando pausas constantes ou ainda não funcionar corretamente. É importante que a tag BANDWIDTH esteja estritamente de acordo com a taxa de bits indicada para o arquivo de índice, para que assim a largura de banda seja suficiente para a perfeita reprodução do streaming. Apple (2011) afirma que é altamente recomendado que exista um fluxo de mídia alternativo, com uma taxa de 64kpb/s ou menor para que, em condições adversas de uma rede de celular onde a velocidade da conexão ficar comprometida, seja possível ainda uma execução constante da mídia. Caso não seja possível gerar um vídeo com uma qualidade aceitável, o autor ainda indica que haja um streaming somente com áudio e com uma imagem fixa. Neste caso é indicado que para uma conexão de celular, o vídeo seja preparado com resolução 400 x 224 para uma proporção de 16:9 e 400 x 300 para uma proporção 4:3.

49

3.1

CODIFICANDO ARQUIVOS DE VÍDEO COM FFMPEG As ferramentas criadas pela Apple para auxiliarem na produção do HTTP Live Stream,

citadas anteriormente, foram desenvolvidas com foco na plataforma MAC OS, a qual é a única com suporte para tais ferramentas. Como dito anteriormente, esta pesquisa tem por intuito a utilização de softwares de código fonte aberto, e como consequência a escolha de uma ferramenta para codificação de mídia que possa estar disponível a todos. Com esta convicção, escolheuse a utilização do aplicativo FFmpeg, que é uma ferramenta de linha de comando, capaz de converter mídias de diversos formatos para muitos outros formatos. O FFmpeg é um software livre, licenciado sob GNU General Public License (GPL) ou GNU Lesser General Public License (LGPL), de acordo com as opções de compilação escolhidas1 . Além disso, seus arquivos binários são compatíveis com a maioria das plataformas, o tornando assim um software com uma interoperabilidade incrivelmente satisfatória para o propósito desta pesquisa. Pela sua notória capacidade, vários outros softwares com interface gráfica foram desenvolvidos para se beneficiar do seu poder de conversão de mídia com o intuito de criar aplicações de fácil utilização para os usuários finais. Como descrito na sessão 3.1, a melhor solução para a tarefa de codificação do conteúdo audiovisual seria utilizando CODEC de vídeo VP8. Porém, pelo fato de não haver um padrão definido, opta-se pela utilização do CODEC H.264 para a codificação e geração dos vídeos e fragmentos necessários para HTTP Live Streaming. Existem várias ferramentas capazes de criar ou converter vídeos para H.264, porém como descrito na sessão 2.3, optou-se pela utilização de uma biblioteca livre, que recebe o nome de X.264. A biblioteca X.264 é publicada pela licença General Public License (GNU). Para sua utilização no FFmpeg, essa biblioteca é chamada pelo apelido “libx264”. Sua utilização por linha de comando permite a inserção de inúmeras opções de codificação, possibilitando uma enorme gama de possibilidades para a geração de vídeos codificados para streaming. Um modelo de sintaxe de utilização do FFmpeg, que é igual para ambas as versões de compilação para diversos sistemas operacionais, pode ser visualizada na figura 13. Como padrão para os exemplos citados neste trabalho, foi utilizado nomenclaturas de arquivos e pastas, bem como testes de funcionamento, em um ambiente Microsoft Windows. Apesar de existir a possibilidade de compilar todo o código fonte do FFmpeg com apenas algumas bibliotecas específicas, por motivo de compatibilidade, além de demonstrar de fato a possibilidade de portabilidade da aplicação e sua facilidade para uso final, optou-se por utilizar a versão Static do FFmpeg. A versão Static, é uma aplicação já compilada com várias outras bibliotecas de conversão de mídia incluMais informações sobre licenças do FFmpeg podem ser visualizadas na página de Considerações Legais do projeto: http://ffmpeg.org/legal.html
1

50

sas. A compilação utilizada para este trabalho foi publicada em 31 de dezembro de 20112 do FFmpeg, atualmente a última versão estável disponível (FFMPEG, 2011).

1

ffmpeg . exe [ opções g l o b a i s ] [ [ opções do a r q u i v o de e n t r a d a ] [ ’-i’ ’arquivo de entrada’ ] ] . . . { [ opções do a r q u i v o de saída ] ’arquivo de saída’ } . . .

Figura 13: Modelo da sintaxe genérica para FFmpeg Com as informações colhidas para esta pesquisa sobre os CODECs de conversões, presentes na sessão 3.1, juntamente com os dados para as combinações de fatores para compressão de dados indicados pela Apple (2011), torna-se possível, utilizando o FFmpeg, gerar novos vídeos com qualidades diferentes para a utilização em ambientes e velocidades de conexões diferentes. O quadro 7 exibe algumas opções, que podem ser utilizadas como parâmetro para a geração destes novos arquivos. A lista completa de parâmetros que podem ser utilizados pode ser visualizado na documentação online do FFmpeg3 . A sequência das opções na montagem da linha de comando para a conversão deve ser escrita cuidadosamente, pois, cada uma das opções interfere na sua opção posterior, tanto para o arquivo de entrada como para o arquivo de saída. Uma opção pode aparecer mais de uma vez em um mesmo comando. Estas regras não se aplicam as opções globais, que são declaradas em primeiro lugar na linha de comando. Todos os parâmetros que aceitam um valor numérico podem aceitar um valor de texto contendo sufixos de acordo com o International System of Units (SI), por exemplo, “Kb”,“Mb”, “Gb” (FFMPEG, 2011). Com base do modelo do comando presente na figura 13, juntamente com alguns modelos de parâmetros que podem ser visto no quadro 7, é possível criar uma linha de comando, simples, capaz de realizar uma conversão. Essa afirmação pode ser confirmada ao vermos uma linha de comando, presente na figura 14, para a conversão de um vídeo original em formato “.avi” para um formato “.ts”. Algumas combinações de parâmetros são muito importantes para a conversão de vídeo que é utilizado em streaming de dados, como por exemplo, a possibilidade de indicar a taxa máxima e mínima de bits variáveis. Essa declaração se dá pela utilização dos parâmetros “qmax” e “-qmin”. Declarar o valor da taxa de bits variáveis, também conhecido na área de vídeo digital como Variable Bit Rate (VBR) ou ainda como Taxa de fluxo de dados variável, permite ao codificador aproveitar o máximo possível cada espaço de tempo. Assim, por exemplo, se não indicado um valor mínimo, o codificador irá reduzir um espaço de tempo que possui um silêncio extremo em um áudio, a um valor de 1Byte/s, que corresponde a 8bit/s. O mesmo pode ocorrer
2 3

Compilação 8475ec1 A documentação online do FFMPEG é acessível pela URL: http://ffmpeg.org/ffmpeg.html

51

Quadro 7: Exemplos de opções de parâmetros para conversão de vídeo utilizando FFmpeg Parâmetro Exemplo -i -i VideoOriginal.avi -ss -ss 0 Detalhes Informa o caminho físico do arquivo original a ser utilizado Busca uma determinada posição de tempo e utiliza como ponto inicial do vídeo, ignorando o espaço de tempo anterior, dentro do arquivo de entrada. Caso sua declaração seja feita nas opções do arquivo de saída, essa posição é obtida do arquivo codificado e, como consequência, possui uma maior precisão. Seu valor pode ser um numero inteiro ou de ponto flutuante, indicando os segundos, ou um valor de texto com padrão “hh:mm:ss[.xxx]” Indica que o aplicativo deve parar de escrever o arquivo de saída após alcançar o valor de tempo definido nesse atributo. Seu valor pode ser um numero inteiro ou de ponto flutuante, indicando os segundos, ou um valor de texto com padrão “hh:mm:ss[.xxx]” Define o tamanho da resolução Define a proporção de tela (aspect ratio) Define a taxa de bits a ser utilizada. Pode ser declarada acompanhando as letras específicas para especificar qual mídia deseja-se atribuir o valor. (:v refere-se a vídeo e :a refere-se a áudio) Define o tamanho do buffer de vídeo (em bits) Define o valor máximo de taxa de bits de vídeo (em bit/s). Exige que seja declarado o parâmetro “-bufsize” na mesma linha de comando Define a taxa de quadros por segundo (fps). Define a tolerância da taxa de bits (padrão 4000k). Este valor define quão longe a taxa de controle pode desviar da taxa de bits média. Define a frequência do áudio (Hz) Define a taxa máxima da escala do quantizador (VBR) do vídeo (bit/s) Define a taxa mínima da escala do quantizador (VBR) do vídeo (bit/s) Define CODEC de vídeo a ser utilizado Define CODEC de áudio a ser utilizado Entende-se como forçar o formato de entrada ou saída. Normalmente, o formato é detectado automaticamente, o que torna essa opção desnecessária na maioria dos casos

-t

-t 10

-s -aspect -b

-s 480x300 -aspect 4:3 -b 64k -b:v 64k -b:a 64k -bufsize 200k -maxrate 200k

-bufsize -maxrate

-r -bt

-r 24 -bt 200k

-ar -qmax -qmin -vcodec -acodec -f

-ar 48000 -qmax 63 -qmin 8 -vcodec libx264 -acodec libvorbis -f mpegts

Adaptado a partir de (FFMPEG, 2011)

52

1

ffmpeg . exe − i e x e m p l o _ o r i g i n a l . a v i −s 640x360 −b : v 1250k −qmax 63 −b : a 56k − a r 22050 −acodec l i b v o r b i s −vcodec l i b x 2 6 4 exemplo_convertido . t s

Figura 14: Modelo da sintaxe genérica para FFmpeg em um espaço de tempo, em um vídeo no caso, em que é necessário uma taxa muito maior, e então o codificador, utilizando o valor configurado através do parâmetro de valor máximo, limita essa taxa. A importância dessa possibilidade está associada ao caso de um mesmo vídeo possuir espaços de tempo e que nenhuma ou mínimas informações são necessárias, e assim otimizando o arquivo em seu escopo geral. Esse fator pode ser entendido de uma forma mais simples, ao descrever-se que quanto maior a taxa de bits, maior será a qualidade e por consequência maior o tamanho físico do arquivo. Da mesma forma, quando menor o bitrate, menor a qualidade e então menor o tamanho físico do arquivo (FFMPEG, 2011) (WAGGONER, 2009). Muitos outros parâmetros poderiam ser citados aqui, porém dentre estes citados até então, proporcionam um bom grupo de opções para geração de vídeos para HTTP Live Streaming. As bibliotecas de conversão em sua maioria possibilitam a utilização de parâmetros próprios, capazes de manipular ainda outros aspectos para geração do vídeo final. Um bom exemplo que pode-se destacar, dentro da biblioteca X.264, é a possibilidade de indicar ao aplicativo conversor a definição de espaço de macroblocos diferentes, através da utilização do parâmetro “-partitions”. Com essa definição de macroblocos, o aplicativo de conversão de vídeo consegue aperfeiçoar a qualidade, removendo bits de partes da imagem que tem menor impacto em longo prazo, como detalhes de transição que duram apenas alguns frames, gerando uma grande eficiência de processamento e melhorias para vídeo final gerado (MANZATO, 2006) (WAGGONER, 2009). Entre tantos parâmetros que proporcionam melhorias no produto final a ser visualizado pelo usuário, existem dois parâmetros que, utilizados em conjunto, possibilitam a criação dos fragmentos de vídeo que são utilizados no HTTP Live Streaming, e assim não gerando a necessidade de utilizar outros aplicativos para os cortes do conteúdo audiovisual. O parâmetro “-ss” indica um tempo inicial, a partir do qual o codificador deve iniciar a leitura, e juntamente com o parâmetro “-t” indica qual o espaço de tempo, a partir do ponto indicado por “-ss”, o codificador deve parar de ler e escrever o arquivo de saída. Dessa maneira, utilizando apenas um arquivo de lote (batch), é possível realizar a divisão do vídeo em pequenos pedaços. Pode-se verificar um exemplo de um arquivo de lote, especificamente um arquivo “.bat” para sua execução em ambiente Windows, na figura 15. O código exemplificado na figura 15, ao ser executado gera-

53

ria um fragmento de vídeo de 10 segundos do vídeo original, e o convertendo para o formato específico utilizado no HTTP Live Streaming.

1 2

@echo o f f ffmpeg . exe −y −ss 0 − t 10 − i "exemplo_original.avi" −vcodec l i b x 2 6 4 − acodec libmp3lame −s 400x224 −aspect 16:9 −qmax 51 −qmin 10 −maxrate 728k − b u f s i z e 728k −b : a 128k −b : v 728k −a r 32000 − b t 728k − r 10 − f mpegts − p a r t i t i o n s + p a r t i 4 x 4 + p a r t p 8 x 8 + p a r t b 8 x 8 "fragment_01.ts"

Figura 15: Exemplo de um arquivo batch para a fragmentação de vídeo utilizando FFmpeg Uma vez, sabendo como realizar a divisão dos fragmentos de vídeo, é possível, através de linguagens de script com a possibilidade de manipulação de arquivos no ambiente executado, criar tarefas automatizadas para a geração dos fragmentos de vídeo finais, bem como os arquivos playlist. Para validação dessas afirmações, optou-se por desenvolver um exemplo funcional, utilizando linguagem script Hypertext Preprocessor (PHP), de um fragmentador de vídeo utilizando FFmpeg. Utilizando como ambiente, um servidor web com sistema operacional Windows e Apache e PHP instalado, foi possível a criação de um script PHP demonstrativo (Apêndice A) para a automatização da tarefa de criar os fragmentos de vídeo juntamente com seu arquivo playlist correspondente. Este script consiste em uma classe, contendo parâmetros com valores pré-definidos para a conversão de vídeo, além de também ser possível a passagem de novos parâmetros para definir outros valores. Estes parâmetros, juntamente com os seus respectivos valores, são utilizados especialmente em uma linha de comando repassado ao executável do FFmpeg, sendo ele capaz de gerar os fragmentos necessários. Cabe neste momento, uma breve descrição de como é a operação do script PHP, que, para fins didáticos desta pesquisa, optou-se por nomeá-lo somente como “PHP HLS Fragmenter ”. Ao ser instanciado a classe do “PHP HLS Fragmenter ”, atribuindo uma nova variável criando um novo Objeto, se faz necessária a passagem de parâmetros obrigatórios. O primeiro parâmetro é o caminho do vídeo de entrada a ser convertido, que deve estar armazenado no mesmo dispositivo que está sendo executado o script. O vídeo de entrada pode estar na pasta “input”, que é específica para organização dos arquivos que serão manipulados pelo “PHP HLS Fragmenter ”, ou então em qualquer outra pasta do sistema e que esteja acessível pelo “PHP HLS Fragmenter ”. Porém neste caso, há a necessidade de ser passado como parâmetro o caminho completo ou relativo do vídeo de entrada. Existem ainda dois outros parâmetros a serem passados, ambos são obrigatórios, porém passando o segundo parâmetro, que é o nome de um dos perfis com parâmetros já definidos dentro do “PHP HLS Fragmenter ”, o terceiro torna-se opcional, pois trata-se de novos atributos.

54

Neste momento, após a nova criação do objeto, o “PHP HLS Fragmenter ” realiza algumas operações como, encontrar o arquivo de vídeo e verificar sua existência, configurar as variáveis de ambiente e obter informações do arquivo de entrada. Caso alguma das operações falhe, um arquivo de texto em formato de log, é gerado na pasta raiz, onde está sendo executado o script, a fim de facilitar correções de configurações. Após as configurações, basta realizar a chamada da função específica para iniciar o procedimento de conversão e fragmentar o vídeo, bem como a criação do arquivo playlist. Utilizando um arquivo de vídeo de entrada, contendo um tempo total de 00:04:13.36 (253.36 segundos), o script PHP gerou 26 fragmentos de vídeo (arquivos “.ts”), os quais foram divididos em tempos iguais de 10 segundos, salvo o último fragmento que recebeu um valor inferior, pois o tempo total do vídeo escolhido não era valor múltiplo de 10. Como padrão para criação das pastas para organizar os fragmentos de vídeos gerados, adotou-se utilizar o valor do parâmetro “-maxrate” como nomenclatura. Desta forma, ao ser gerado os fragmentos diferentes para um mesmo vídeo, o script criará pastas específicas para cada grupo de fragmentos, dentro da pasta “output”, com o valor de “-maxrate”. Os fragmentos, por sua vez, recebem como nome um prefixo, precedido do número do fragmento, juntamente com a terminação “.ts”. Da mesma forma, o arquivo playlist “M3U8”, também recebe o nome de acordo com o valor “-maxrate”, e por padrão é salvo na pasta “output”. Assim sendo facilmente criado uma estrutura organizada para facilitar a manipulação do conjunto de todos os arquivos gerados na operação, que pode ser visualizada na figura 16.

Figura 16: Exemplo de organização de pastas criadas pelo “PHP HLS Fragmenter ” De acordo com o que foi exposto, foi possível criar versões do mesmo segmento para taxas de bits diferentes, como 88kpb/s, 206kpb/s e 728kpb/s utilizando o “PHP HLS Fragmenter ”. Pode ser verificado no apêndice B, o exemplo do arquivo utilizado para as chamadas ao script para este procedimento. Com os fragmentos e os arquivos playlist, criou-se um arquivo

55

de índice mestre, composto com as informações necessárias para então criar um conjunto de vídeos alternativos para um streaming utilizando HTTP Live Streaming. Após a criação dos fragmentos pelo “PHP HLS Fragmenter ”, há a necessidade da criação do arquivo de índice mestre manualmente. O exemplo do arquivo mestre final pode ser verificado na figura 17.

1 2 3 4 5 6 7

#EXTM3U #EXT−X− STREAM INF :PROGRAM ID =1 ,BANDWIDTH=1280000 − − 88k . m3u8 #EXT−X− STREAM INF :PROGRAM ID =1 ,BANDWIDTH=2560000 − − 206k . m3u8 #EXT−X− STREAM INF :PROGRAM ID =1 ,BANDWIDTH=7680000 − − 728k . m3u8

Figura 17: Arquivo mestre final, criado para utilizar os arquivos gerados pelo “PHP HLS Fragmenter ” Com os fragmentos de vídeos, juntamente com os arquivos playlists, arquivos de índice e um arquivo HTML, é necessário torná-los disponíveis a partir de uma URL. Para tal, é preciso mover a estrutura do conjunto de arquivos gerados para um servidor web cache como, por exemplo, um servidor Apache, que receberá as requisições da aplicação cliente. Sendo realizado as atividades como descritas anteriormente, a configuração do servidor web que pode ser visto na figura 12, e criado o arquivo HTML contando as informações com a tag <video> e armazená-lo juntamente na pasta acessível do servidor web cache, acredita-se que o componente de distribuição está preparado. Para a validação desse resultado obtido da conversão e fragmentos do vídeo original, foi utilizado um navegador web Safari, em um ambiente Mac OS X Lion. Ao se acessar a URL contendo o arquivo HTML (Apêndice C), com a tag <video> apontando para o arquivo de índice, o vídeo inicia sua reprodução buscando cada fragmento, sequencialmente, do servidor. Como dito anteriormente, de acordo com a possibilidade de maior taxa de transferência da rede, e de acordo com o consumo de processamento no ambiente do dispositivo que está reproduzindo o vídeo, o player então busca os fragmentos indicados com maior qualidade ou menor, de acordo com a decisão do player. Um exemplo dessa troca de qualidades pode ser vista no log de acesso do servidor web cache, exibido no Apêndice D. Assim como o script “PHP HLS Fragmenter ”, existe a possibilidade de desenvolvimento de diversos outros aplicativos, aproveitando as possibilidades do ambiente atual, bem como novas funcionalidades apoiadas na linguagem de script a ser utilizada, facilitando ainda mais ao usuário. Face ao que foi exposto, pode-se entender que a aplicação responsável pela recepção da mídia original, sendo ela gravada ou ao vivo, e a converter para o formato funcional para

56

HTTP Live Streaming, além de fragmentar e gerar seu arquivo playlist respectivo, é considerada o objeto principal de uma ferramenta para criação de ambientes que utilizem Streaming Adaptativo, principalmente no âmbito do HTTP Live Streaming. Diversas são as possibilidades de desenvolvimento de aplicações para tal funcionalidade, desde que se mantenham os princípios necessários para seu funcionamento. As atribuições de novas funcionalidades, como interface gráfica, organizador e manipulador automático de pastas, geração de arquivos de índices, entre outros, podem enriquecer ainda mais as ferramentas a serem desenvolvidas para a criação de streaming de vídeo utilizando HTTP Live Streaming e facilitar a utilização dessas pelos usuários finais.

57

4

CONCLUSÃO

Este estudo abordou aspectos relevantes da tecnologia streaming, utilizando a adaptabilidade como área de pesquisa dentre as inúmeras possibilidades existentes para a distribuição de conteúdos audiovisuais dentro dessa tecnologia. Aprofundou-se no entendimento de um método relativamente novo de distribuição adaptativa, chamado de HTTP Live Streaming, desenvolvida pela empresa Apple, capaz de realizar a adaptação sem a necessidade de aplicações específicas para a distribuição de streaming. Com o intuito de estudar os métodos de distribuição de vídeo, durante o desenvolver deste trabalho, foi necessário efetivar uma pesquisa para levantar os fatores que tornaram o Streaming por HTTP popularmente conhecido. Um estudo completo em pesquisas bibliográficas sobre métodos e tecnologias de distribuição de vídeo, foi desenvolvido a fim de criar definições de streaming, bem como a explicar os três principais métodos de distribuição desta tecnologia: Streaming Tradicional, HTTP Progressive Download e HTTP Streaming. Este estudo foi capaz de descrever as definições de HTTP Streaming Adaptativo, e desta forma, possibilitar um bom entendimento do HTTP Live Streaming, o qual faz parte deste método de distribuição. Apresentou-se ainda, alguns comparativos entre outras tecnologias que utilizam a adaptação como o método principal de distribuição. Embora não fosse o foco principal deste trabalho, fez-se necessário um breve levantamento de CODECs e contêineres de vídeos, para utilização de HTTP Live Streaming. Por se tratar de um método recente, o HTTP Live Streaming possui um número limitado de trabalhos científicos em sua área. Para tal, houve a necessidade de leituras em manuais e documentações, a fim de tornar possível o entendimento do seu funcionamento, para a aplicação proposta para este trabalho. Por este motivo, bem como o tempo para o desenvolvimento deste trabalho foi demasiadamente curto para todos os objetivos propostos, alguns pontos não puderam ser alcançados dentro desta pesquisa, como, por exemplo, levantar os requisitos necessários para um sistema de captura de áudio e vídeo. Com o intuito de criar um estudo em potencial, capaz de minimizar as necessidades de aplicações e conhecimentos avançados para a distribuição de streaming, a implementação deste estudo baseando-se em diversos sistemas operacionais, tornou-se inviável no decorrer deste trabalho. Com base em referências analisadas para a elaboração deste estudo, pode-se observar claramente a potencialidade do método de distribuição HTTP Live Streaming. Apesar de sua aplicação ainda estar limitada a dispositivos com sistemas operacionais desenvolvidos pela empresa Apple, foi possível encontrar outros desenvolvedores inserindo este método nativamente em seus sistemas operacionais. Por sua documentação estar disponível através de um draft

58

de RFC, apesar de extensa, é facilmente entendível seu funcionamento, tornando possível a criação de novas aplicações capazes de suportar tal método de streaming. Como exemplo, neste trabalho foi apresentado um protótipo funcional como parte de um produto completo, o qual é capaz de obter uma mídia previamente gravada, e prepará-la para distribuição utilizando aplicativos e bibliotecas de código aberto. O HTTP Live Streaming, é desenvolvido para utilizar-se das novas possibilidades de inserção de vídeo em páginas web que utilizam HTML5, tornando assim pelo cliente, a execução dos conteúdos enviados pelo servidor de distribuição, facilmente visualizado sem a necessidade de instalação de plugins ou aplicações adicionais. Mesmo que esta versão do HTML ainda não esteja totalmente publicada, seu estudo é potencialmente válido, pois se trata de uma atualização global da atual versão do HTML, utilizado nos principais navegadores. Apesar das dificuldades encontradas para o desenvolvimento da aplicação proposta neste trabalho, o objetivo geral foi alcançado, pois foi possível expor o funcionamento do método HTTP Live Streaming, bem como entender o ambiente necessário para seu funcionamento, e ainda com propósito de uma solução com base código aberta, sem custo com royalties. Com esses resultados, acredita-se que o HTTP Live Streaming é uma poderosa ferramenta de distribuição de streaming. Por este motivo, apontam-se possíveis trabalhos futuros, a fim de elaborar soluções completas para este método, incluindo ferramentas multiplataformas com possibilidade de usar canais de entrada de vídeo, gravado em outro período temporal ou ao vivo.

59

REFERÊNCIAS ADAO, C. M. C. de J. Tecnologias de Streaming em Contextos de Aprendizagem. 2006. Dissertação de Mestrado (Mestre em Sistemas de Informação) - Departamento de Sistemas de Informação, Universidade do Minho, Guimarães, PT, 2006. ADOBE, D. M. G. A Streaming Media Primer. 2001. Adobe Systems, Inc. Disponível em: <http://goo.gl/WSW9L>. Acesso em: 18 de set. de 2011. ADOBE, S. I. HTTP Dynamic Streaming on the Adobe Flash Platfor. 2010. Disponível em: <http://goo.gl/29nlw>. Acesso em: 20 de set. de 2011. ADOBE, S. I. Perguntas frequentes sobre HTTP Dynamic Streaming. 2011. Disponível em:

<http://goo.gl/7EGhm>. Acesso em: 26 de set. de 2011.
AKHSHABI, S.; BEGEN, A. C.; DOVROLIS, C. An Experimental Evaluation of Rate Adaptation Algorithms in Adaptive Streaming over HTTP. 2011. Multimedia Systems Conference, San Jose, California, USA, February, 2011. APPLE, I. HTTP Live Streaming Overview. 2011. Disponível em: <http://goo.gl/f8jV8>. Acesso em: 30 de set. de 2011. BERNERS-LEE, T. et al. RFC 2616: Hypertext Transfer Protocol – HTTP/1.1. Fremont, California, USA, June 1999. BHANDARKAR, S. M.; CHATTOPADHYAY, S.; GARLAPATI, S. S. A Hybrid Layered Video Encoding Technique for Mobile Internet-based Vision. 2010. Part of LECTURE NOTES IN COMPUTER SCIENCE vol.5960 - Mobile Multimedia Processing Fundamentals, Methods, and Applications. BRYANT, S. Videoblogging for Dummies. [S.l.]: John Wiley & Sons, 2006. (For Dummies). ISBN 9780471971771. DARAS, P.; IBARRA, O. M. User Centric Media. Venice, Italy: First International Conference, UCMedia 2009, 2009. ISBN: 1867-8211. FFMPEG. FFmpeg Documentation. 2011. Disponível em: <http://goo.gl/K07u9>. Acesso em: 04 de nov. de 2011. GHANBARI, M. Standard codecs: image compression to advanced video coding. London, UK: Institute of Electrical Engineers, 2003. GHOSH, J.; CAMERON, R. Silverlight Recipes: A Problem Solution Approach, Second Edition. [S.l.]: Apress, 2010. (Apress Series). ISBN 9781430230335. ISLAM, M. S. A HTTP Streaming Video Server with Dynamic Advertisement Splicing. 2010. Master of Science Thesis, Royal Institute of Technology (KTH) School of Information and Communication Technology, Stockholm - Sweden. JACOBS, M.; PROBELL, J. A Brief History of Video Coding. 2007. ARC International. KOMATINENI et al. Pro Android 3. [S.l.]: Apress, 2011. (Apress Series). ISBN 9781430232223.

60

KOZAMERNIK, F. Media Streaming over the Internet — an overview of delivery technologies. 2002. EBU Technical Department. KUROSE, J. F.; ROSS, K. W. Computer networking: a top-down approach. 5. ed. Boston, MA: Pearson Education , Inc, 2010. LARSON, L.; COSTANTINI, R. Flash Video for Professionals: Expert Techniques for Integrating Video on the Web. Indianapolis, Indiana: Wiley Publishing, Inc., 2007. ISBN: 978-0-470-13113-8. LIM, Y.; SINGER, D. RFC 4337: MIME Type Registration for MPEG-4. Fremont, California, USA, March 2006. MACDONALD, M. Pro Silverlight 3 in VB. [S.l.]: Apress, 2009. (Apress Series). ISBN 9781430224273. MANZATO, M. G. Técnicas e Padrões de Codificação de Vídeo. 2006. Trabalho de Conclusão de Curso (Bacharel em Ciência da Computação) - Departamento de Computação, Universidade Estadual de Londrina, Londrina, PR, 2004. MICROSOFT, C. Smooth Streaming. 2011. Disponível em: <http://goo.gl/BQX89>. Acesso em: 18 de set. de 2011. MITCHELL, J. L. MPEG video compression standard. Norwell, MA: Kluer Academic Publishers, 2000. O’REILLY, T. MPEG LA News Release. 2010. Disponível em: <http://goo.gl/lVv1V>. Acesso em: 16 de out. de 2011. PANSANATO, G. C. Análise detalhada de CODECS e estudos relacionados. 2005. Relatório de Estágio Curricular (Bacharelado em Ciência da Computação) - Universidade Estadual de Londrina, Londrina - SC. PANTOS, E. R. Internet-Draft: HTTP Live Streaming (work in progress). Fremont, California, USA, September 2011. Expira em: 2 de Abril de 2012. PFEIFFER, S. The Definitive Guide to HTML5 Video. [S.l.]: Apress, 2010. (Definitive Guide Series). ISBN 9781430230908. POWERS, S. HTML5 Media. [S.l.]: O´Reilly Media, 2011. ISBN 9781449315313. RICHARDSON, I. E. G. H.264 and MPEG-4 Video Compression: Video Coding for Next Generation Multimedia. Southem Gate, Chichester, West Susex PO19, England: John Wiley I& Sons Ltd. The Atrium, 2003. ISBN: 0 4708483-7-5. SAMPAIO, C. JAVA - ENTERPRISE EDITION 6: DESENVOLVENDO APLICAÇOES CORPORATIVAS. BRASPORT, 2011. ISBN 9788574524603. Disponível em: <http://books.google.com/books?id=FZbNJIma0noC>. SCHULZRINNE, H. RFC 2326: Real Time Streaming Protocol (RTSP). Fremont, California, USA, April 1998. SCHULZRINNE, H. et al. RFC 3550: RTP: A Transport Protocol for Real-Time Applications. Fremont, California, USA, July 2003.

61

TABORDA, P. Terminal IPTV para Visualização de Sessões de Colaboração Multimédia. 2010. Dissertação de Mestrado em Engenharia Informática - Universidade Nova de Lisboa Faculdade de Ciências e Tecnologia Departamento de Informática, 2010. THORNHILL, S.; ASENSIO, M.; YOUNG, C. Video Streaming: a guide for educational development. PO Box 88, Manchester: The JISC Click and Go Video Project, ISD, UMIST, 2002. ISBN: 0 9543804-0-1. TIWARI, S.; ELROM, E. AdvancED Flex 4. New York, NY: Springer Science Bussines Media LLC., 2010. ISBN: 978-1-4302-2484-6. WAGGONER, B. Compression for Great Video and Audio: Master Tips and Common Sense. [S.l.]: Elsevier Science & Technology, 2009. (DV Expert Series). ISBN 9780240812137. ZAMBELLI, A. IIS Smooth Streaming Technical Overview. 2009. Media Technology Evangelist. Disponível em: <http://goo.gl/szRgf>. Acesso em: 23 de set. de 2011. ZAPATA, M. G. Securing and enhancing routing protocols for mobile ad hoc networks. 2006. Doctorate in Computer Architecture and Technology Computer Architecture Department (DAC), Barcelona, March 2006.

62

APÊNDICES

63

APÊNDICE A - SCRIPT PHP PARA GERAÇÃO DE FRAGMENTOS COM FFMPEG
1 3 5 7 8 9 10 11 13 14 15 17 19 21 22 23 24 25 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53
<?php

r e q u i r e _ o n c e ( "getid3/getid3.php" ) ;

c l a s s FFmpeg_HLS_conversion_test {

v a r $FFmpeg_path var $output_path var $input_path var $ l o g _ f i l e var $ i n p u t _ f i l e

= NULL ; = "output" ; = "input" ; = "./log_conversion.log" ; = NULL ;

v a r $parameters v a r $secondsFragment var $ u s e _ t h i s _ p r o f i l e

= NULL ; = 10; = NULL ;

var $ T h i s F i l e I n f o

= NULL ;

v a r $getID3

= NULL ;

/ / o p t i o n "− y " // i f $ o v e r w r i t e _ f i l e s == FALSE , i n s e r t s u f f i x t o f i l e n a m e = TRUE; = "fragment_" ; = "playlist.m3u8" ;

var $ o v e r w r i t e _ f i l e s v a r $p re fi x_ se gme nt s var $ p l a y l i s t _ o u t

var $ p r o f i l e s = Array (

"mobile_16x9_128k"

=> A r r a y (

"-vcodec"
, "-acodec" , "-s" , "-aspect" , "-qmax" , "-qmin" , "-maxrate" , "-bufsize" , "-b:a" , "-b:v" , "-ar" , "-t" , "-bt" , "-r" , "-f"

=> "libx264" => "libmp3lame" => "400x224" => "16:9" => 51 => 10 => "88k" => "88k" => "32k" => "88k" => 32000 => 10 => "88k" => 10 => "mpegts"

, "-partitions" => "+parti4x4+partp8x8+partb8x8" ) , "mobile_16x9_256k" => A r r a y (

"-vcodec"
, "-acodec" , "-s" , "-aspect" , "-qmax" , "-qmin" , "-maxrate"

=> "libx264" => "libmp3lame" => "400x224" => "16:9" => 51 => 10 => "206k"

64

54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 90 92 93 94 95 96 97 98 99 100 101 103 104 105 106

, "-bufsize" , "-b:a" , "-b:v" , "-ar" , "-t" , "-bt" , "-r" , "-f"

=> "206k" => "88k" => "206k" => 32000 => 10 => "206k" => 10 => "mpegts"

, "-partitions" => "+parti4x4+partp8x8+partb8x8" ) , "mobile_16x9_768k" => A r r a y (

"-vcodec"
, "-acodec" , "-s" , "-aspect" , "-qmax" , "-qmin" , "-maxrate" , "-bufsize" , "-b:a" , "-b:v" , "-ar" , "-t" , "-bt" , "-r" , "-f"

=> "libx264" => "libmp3lame" => "400x224" => "16:9" => 51 => 10 => "728k" => "728k" => "128k" => "728k" => 32000 => 10 => "728k" => 10 => "mpegts"

, "-partitions" => "+parti4x4+partp8x8+partb8x8" ) ); / / $original_filename / / $use_profile profile / / $parameters Array a d d i t i o n a l parameters string bool or s t r i n g filename or f u l l p a t h + filename name o f e x i s t i n g p r o f i l e , o r FALSE t o does n o t use

f u n c t i o n _ _ c o n s t r u c t ( $ o r i g i n a l _ f i l e n a m e , $ u s e _ p r o f i l e = FALSE, $parameters = A r r a y ( ) ) { $ t h i s −>updatePaths ( ) ; $ t h i s −>set_PathFFmpeg ( ) ;

$ t h i s −>getID3 = new getID3 ;

i f ( is_file ( $original_filename ) ) { $ t h i s −>s e t _ I n p u t F i l e ( $ o r i g i n a l _ f i l e n a m e ) ; } else i f ( i s _ f i l e ( $ t h i s −>i n p u t _ p a t h . $ o r i g i n a l _ f i l e n a m e ) ) { $ t h i s −>s e t _ I n p u t F i l e ( $ t h i s −>i n p u t _ p a t h . $ o r i g i n a l _ f i l e n a m e ) ; } i f ( i s s e t ( $parameters ) && i s _ a r r a y ( $parameters ) && count ( $parameters ) >0) { foreach ( $parameters as $param => $value ) { $ t h i s −>add_parameter ( $param , $value ) ; } }

i f ( $ u s e _ p r o f i l e !== FALSE) { i f ( ! $ t h i s −>s e t _ P r o f i l e ( $ u s e _ p r o f i l e ) ) { i f ( ! i s s e t ( $ t h i s −>parameters ) ) { $ t h i s −>w r i t e _ l o g ( "Pameter and Profile Not Found!" ) ;

65

107 108 109 110 111 112 114 115 116 117 118 119 120 121 122 123 124 125 127 128 129 130 131 133 134 135 136 137 138 139 140 141 143 144 145 146 148 149 150 152 153 154 156 157 159 160

exit ( ) ; } } } $ t h i s −>g e t _ I n f o I n p u t F i l e ( ) ; }

f u n c t i o n set_PathFFmpeg ( $ f u l l P a t h = ’’ ) { i f ( $ f u l l P a t h ! = ’’ ) { if ( is_file ( $fullPath ) ) { $ t h i s −>FFmpeg_path = $ f u l l P a t h ; } else { $ t h i s −>w r i t e _ l o g ( "FFmpeg file Not Found!" ) ; exit ( ) ; } } else { $ t h i s −>FFmpeg_path = getcwd ( ) .DIRECTORY_SEPARATOR. "ffmpeg.exe" ; } }

/ / TODO: improve t h i s f u n c t i o n : / f u n c t i o n updatePaths ( ) { $ t h i s −>o u t p u t _ p a t h = getcwd ( ) .DIRECTORY_SEPARATOR. $ t h i s −>o u t p u t _ p a t h . DIRECTORY_SEPARATOR; $ t h i s −>i n p u t _ p a t h = getcwd ( ) .DIRECTORY_SEPARATOR. $ t h i s −>i n p u t _ p a t h . DIRECTORY_SEPARATOR; }

/ / $param / / $value

string string

f u n c t i o n add_parameter ( $param , $value ) { i f ( $param == "-t" ) { $ t h i s −>set_secondsFragment ( $value ) ; } else i f ( $param ! = "-ss" && $param ! = "" ) { $ t h i s −>parameters [ $param ] = $value ; } }

/ / $inputFile

string

filename or f u l l p a t h + filename

function set_InputFile ( $inputFile ) { $ t h i s −> i n p u t _ f i l e = $ i n p u t F i l e ; }

function set_PlayListFile ( $PlayListFile ) { $ t h i s −> p l a y l i s t _ o u t = $ P l a y L i s t F i l e ; }

f u n c t i o n set_secondsFragment ( $secondsFragment ) { $ t h i s −>secondsFragment = $secondsFragment ; }

/ / $profileName

string

p r o f i l e name

f u n c t i o n s e t _ P r o f i l e ( $profileName ) {

i f ( i s s e t ( $ t h i s −> p r o f i l e s [ $profileName ] ) ) { $ t h i s −>u s e _ t h i s _ p r o f i l e = $profileName ;

66

161 162 163 164 165 166 167 168 169 170 171 172 173 175 176 177 178 179 180 181 182 183 185 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213

i f ( i s _ a r r a y ( $ t h i s −> p r o f i l e s [ $profileName ] ) && count ( $ t h i s −> p r o f i l e s [ $profileName ] ) >0) { foreach ( $ t h i s −> p r o f i l e s [ $profileName ] as $ P r o f i l e P a r a m => $Pr of il ePa ra mV alu e ) { / / do n o t o v e r w r i t e i f ( ! i s s e t ( $ t h i s −>parameters [ $ P r o f i l e P a r a m ] ) ) { $ t h i s −>add_parameter ( $ProfileParam , $P rof il ePa ra mV alu e ) ; } } } r e t u r n TRUE; } else { r e t u r n FALSE ; } }

f u n c t i o n get_CommandLineWithParameters ( ) { $cmd = " ";

i f ( i s s e t ( $ t h i s −>parameters ) && i s _ a r r a y ( $ t h i s −>parameters ) && count ( $ t h i s −>parameters ) >0) { foreach ( $ t h i s −>parameters as $parameter => $value ) { $cmd . = $parameter . " " . $value . " " ; } } r e t u r n $cmd ; }

f u n c t i o n make_HeaderPlaylist ( ) {

$ s t r _ h e a d e r = "#EXTM3U\n" ; i f ( i s s e t ( $ t h i s −>secondsFragment ) && $ t h i s −>secondsFragment ! = "" ) { $ s t r _ h e a d e r . = "#EXT-X-TARGETDURATION:" . $ t h i s −>secondsFragment . "\n" ; } else { $ t h i s −>w r i t e _ l o g ( "FragmentTime (TARGETDURATION) property Not Found!" ) ; exit ( ) ; } $ s t r _ h e a d e r . = "#EXT-X-MEDIA-SEQUENCE:0\n" ; i f ( i s _ f i l e ( $ t h i s −> p l a y l i s t _ o u t ) ) { i f ( $ t h i s −> o v e r w r i t e _ f i l e s === FALSE) { $now = time ( ) ; $ t h i s −> p l a y l i s t _ o u t = $now . "_" . $ t h i s −> p l a y l i s t _ o u t ; } else { u n l i n k ( $ t h i s −> p l a y l i s t _ o u t ) ; } } $ t h i s −> w r i t e _ P l a y l i s t ( $ s t r _ h e a d e r ) ; } f u n c t i o n make_FragmentPlaylist ( $time , $name ) { $ s t r = "#EXTINF:" . $time . ",\n" ; $ s t r . = $name . "\n" ; $ t h i s −> w r i t e _ P l a y l i s t ( $ s t r ) ; } f u n c t i o n make_EndPlaylist ( ) { $ s t r = "#EXT-X-ENDLIST" ; $ t h i s −> w r i t e _ P l a y l i s t ( $ s t r ) ; }

67

215 216 217 218 219 220 221 222 223 225 226

f u n c t i o n create_segments ( ) { $command_line = "\"" . $ t h i s −>FFmpeg_path . "\"" ; i f ( $ t h i s −> o v e r w r i t e _ f i l e s ) { $command_line . = " -y " ; } $ c o m m a n d _ l i n e _ i n p u t _ f i l e . = " -i \"" . $ t h i s −> i n p u t _ f i l e . "\" " ; $params = $ t h i s −>get_CommandLineWithParameters ( ) ; i f ( i s s e t ( $ t h i s −>T h i s F i l e I n f o [ ’playtime_seconds’ ] ) ) { $time = $ t h i s −>T h i s F i l e I n f o [ ’playtime_seconds’ ] ;

/ / a d j us t m e nt f o r " Maximum e x e c u t i o n t i m e " on PHP s c r i p t s e t _ t i m e _ l i m i t ( $time ∗ 2 . 3 ) ;

229 230 231 232 233 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 256 257 258 259 260 261 262 263 265

$ f r a g m e n t s _ i n t e g e r s = f l o o r ( ( $time−$ l a s t _ f r a g m e n t ) / $ t h i s −>secondsFragment ) ; $last_fragment = c e i l ( $time −( $ f r a g m e n t s _ i n t e g e r s ∗ $ t h i s −>secondsFragment ) ) ;

i f ( $ l a s t _ f r a g m e n t == 0 ) { $ l a s t _ f r a g m e n t = FALSE ; }

$path_out = $ t h i s −>o u t p u t _ p a t h ; $ p l a y l i s t _ o u t = $ t h i s −>o u t p u t _ p a t h ; i f ( i s s e t ( $ t h i s −>parameters [ "-maxrate" ] ) && $ t h i s −>parameters [ "-maxrate" ] ! = "" ) { $ p l a y l i s t _ o u t . = $ t h i s −>parameters [ "-maxrate" ] . ".m3u8" ; $ f r a g m e n t _ o u t _ r e l a t i v e = $ t h i s −>parameters [ ’-maxrate’ ] . DIRECTORY_SEPARATOR; } else { $ t h i s −>w r i t e _ l o g ( "FragmentTime (TARGETDURATION) property Not Found!" ) ; exit ( ) ; } i f ( ! i s _ d i r ( $path_out .DIRECTORY_SEPARATOR . $ f r a g m e n t _ o u t _ r e l a t i v e ) ) { i f ( mkdir ( $path_out .DIRECTORY_SEPARATOR . $ f r a g m e n t _ o u t _ r e l a t i v e , 775 , TRUE) ) { $ t h i s −>w r i t e _ l o g ( "Creating path out! (" . $path_out .DIRECTORY_SEPARATOR. $ f r a g m e n t _ o u t _ r e l a t i v e . ")" ) ; } else { $ t h i s −>w r i t e _ l o g ( "Error on create path out! (" . $path_out .DIRECTORY_SEPARATOR. $ f r a g m e n t _ o u t _ r e l a t i v e . ")" ) ; } } / / s e t P l a y l i s t name $ t h i s −>s e t _ P l a y L i s t F i l e ( $ p l a y l i s t _ o u t ) ; / / create p l a y l i s t file

$ t h i s −>make_HeaderPlaylist ( ) ;

i f ( ! i s _ w r i t a b l e ( $path_out .DIRECTORY_SEPARATOR . $ f r a g m e n t _ o u t _ r e l a t i v e ) ) { $ t h i s −>w r i t e _ l o g ( "Path Out is not writable! (" . $path_out .DIRECTORY_SEPARATOR. $ f r a g m e n t _ o u t _ r e l a t i v e . ")" ) ; exit ( ) ; } $now = time ( ) ; $timeSeconds = 0 ; f o r ( $currentFragment = 1 ; $currentFragment <= $ f r a g m e n t s _ i n t e g e r s ; $currentFragment ++) { $fragment = $ f r a g m e n t _ o u t _ r e l a t i v e . "" . $ t h i s −>p r e f i x _ s e g m e n t s . $currentFragment . ".ts" ;

i f ( i s _ f i l e ( $path_out . $fragment ) && $ t h i s −> o v e r w r i t e _ f i l e s === FALSE) {

68

266 267

$fragment = $ f r a g m e n t _ o u t _ r e l a t i v e . $ t h i s −>p r e f i x _ s e g m e n t s . "_" . $now . "_" . $currentFragment . ".ts" ; f i l e _ p u t _ c o n t e n t s ( "exec_temp.cmd" , $command_line . "

-ss " . $timeSeconds . " -t " . $ t h i s

−>secondsFragment . " " . $ c o m m a n d _ l i n e _ i n p u t _ f i l e . " " . $params . " \"" . $path_out .
$fragment . "\"" ) ;

268 269 270 271

passthru ( "exec_temp.cmd" ) ; $ t h i s −>w r i t e _ l o g ( "Creating fragment: } else { f i l e _ p u t _ c o n t e n t s ( "exec_temp.cmd" , $command_line . " -ss " . $timeSeconds . " -t " . $ t h i s

(\"" . $path_out . $fragment . "\") " ) ;

−>secondsFragment . " " . $ c o m m a n d _ l i n e _ i n p u t _ f i l e . " " . $params . " \"" . $path_out .
$fragment . "\"" ) ;

272 273 274 275 276 277 278 279 280 281 282 283

passthru ( "exec_temp.cmd" ) ; $ t h i s −>w r i t e _ l o g ( "Creating fragment: } / / add segment t o p l a y l i s t $ t h i s −>make_FragmentPlaylist ( $ t h i s −>secondsFragment , s t r _ r e p l a c e ( "\\" , "/" , $fragment ) ) ; $timeSeconds = $currentFragment ∗ $ t h i s −>secondsFragment ; } i f ( $ l a s t _ f r a g m e n t !== FALSE) { $fragment = $ f r a g m e n t _ o u t _ r e l a t i v e . "" . $ t h i s −>p r e f i x _ s e g m e n t s . $currentFragment . ".ts" ; i f ( i s _ f i l e ( $path_out . "" . $ t h i s −>p r e f i x _ s e g m e n t s . $currentFragment . ".ts" ) && $ t h i s −> o v e r w r i t e _ f i l e s === FALSE) { $fragment = $ f r a g m e n t _ o u t _ r e l a t i v e . $ t h i s −>p r e f i x _ s e g m e n t s . "_" . $now . "_" . $currentFragment . ".ts" ; f i l e _ p u t _ c o n t e n t s ( "exec_temp.cmd" , $command_line . "

(\"" . $path_out . $fragment . "\") " ) ;

-ss " . $timeSeconds . " -t " .

$ l a s t _ f r a g m e n t . " " . $ c o m m a n d _ l i n e _ i n p u t _ f i l e . " " . $params . " \"" . $path_out . "" . $fragment . "\"" ) ;

285 286 288 289

passthru ( "exec_temp.cmd" ) ; $ t h i s −>w r i t e _ l o g ( "Creating fragment:

(" . $path_out . $fragment . ") " ) ;

} else { f i l e _ p u t _ c o n t e n t s ( "exec_temp.cmd" , $command_line . " -ss " . $timeSeconds . " -t " . $ l a s t _ f r a g m e n t . " " . $ c o m m a n d _ l i n e _ i n p u t _ f i l e . " " . $params . " \"" . $path_out . "" . $fragment . "\"" ) ;

291 292 293 294 295 296 297 298 299 300 301 302 303 305 306 307 308

passthru ( "exec_temp.cmd" ) ; $ t h i s −>w r i t e _ l o g ( "Creating fragment: } / / add segment t o p l a y l i s t $ t h i s −>make_FragmentPlaylist ( $ l a s t _ f r a g m e n t , s t r _ r e p l a c e ( "\\" , "/" , $fragment ) ) ; } / / end p l a y l i s t file

(" . $path_out . $fragment . ") " ) ;

$ t h i s −>make_EndPlaylist ( ) ; } else { $ t h i s −>w r i t e _ l o g ( "playtime_seconds ID3 property Not Found!" ) ; exit ( ) ; } }

//

$ f i l e == f u l l path + f i l e n a m e & e x t e n s i o n

function get_InfoInputFile () { $ t h i s −>T h i s F i l e I n f o = $ t h i s −>getID3 −>analyze ( $ t h i s −> i n p u t _ f i l e ) ; }

69

310 311 312 313 314 315 316 317

f u n c t i o n w r i t e _ l o g ( $msg ) { $msg = "\nLog (" . date ( ’Y-m-d H:i:s’ ) . ") : " . $msg ;

f i l e _ p u t _ c o n t e n t s ( $ t h i s −> l o g _ f i l e , $msg , FILE_APPEND ) ; } f u n c t i o n w r i t e _ P l a y l i s t ( $msg ) { f i l e _ p u t _ c o n t e n t s ( $ t h i s −>p l a y l i s t _ o u t , utf8_encode ( $msg ) , FILE_APPEND ) ; } }

APÊNDICE B - SCRIPT PHP PARA CHAMADA A BIBLIOTECA PHP HLS FRAGMENTER
1 2 4 5 7 8 10 11 13
<?php include "includes/ffmpeg_HLS_conversion.php" ;

$ co n v er s i on = New FFmpeg_HLS_conversion_test ( "exemplo_original.avi" , ’mobile_16x9_128k’ ) ; $conversion −>create_segments ( ) ;

$ co n v er s i on = New FFmpeg_HLS_conversion_test ( "exemplo_original.avi" , ’mobile_16x9_256k’ ) ; $conversion −>create_segments ( ) ;

$ co n v er s i on = New FFmpeg_HLS_conversion_test ( "exemplo_original.avi" , ’mobile_16x9_768k’ ) ; $conversion −>create_segments ( ) ;

?>

APÊNDICE C - CÓDIGO HTML5 CONTENDO CHAMADAS AO ARQUIVO DE ÍNDICE HLS
1 2 3 4 5 6 7 8 9 10 11
<html> <head> < t i t l e >Test < / t i t l e > <meta name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable

=0;" / >
< / head> <body s t y l e ="background-color:#FFFFFF; "> <center> < v i d e o src="indexFile.m3u8" c o n t r o l s a u t o p l a y >< / v i d e o > < / center> < / body> < / html>

70

APÊNDICE D - FRAGMENTO DE LOG DO APACHE CONTENDO O HISTÓRICO DE REQUISIÇÕES AOS ARQUIVOS DE ÍNDICE E FRAGMENTOS
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
[ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 6 : 1 9 −0200] "GET / h l s −t e s t / o u t p u t / HTTP / 1 . 1 " 200 286 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 6 : 2 0 −0200] "GET / h l s −t e s t / o u t p u t / i n d e x F i l e . m3u8 HTTP / 1 . 1 " 206 2 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 6 : 2 0 −0200] "GET / h l s −t e s t / o u t p u t / i n d e x F i l e . m3u8 HTTP / 1 . 1 " 206 189 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 6 : 2 1 −0200] "GET / h l s −t e s t / o u t p u t / 8 8 k . m3u8 HTTP / 1 . 1 " 200 867 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 6 : 2 1 −0200] "GET / h l s −t e s t / o u t p u t / 8 8 k / fragment_1 . t s HTTP / 1 . 1 " 200 155852 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 6 : 2 1 −0200] "GET / h l s −t e s t / o u t p u t / 8 8 k / fragment_2 . t s HTTP / 1 . 1 " 200 168824 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 6 : 2 3 −0200] "GET / h l s −t e s t / o u t p u t / 8 8 k / fragment_3 . t s HTTP / 1 . 1 " 200 168448 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 6 : 2 5 −0200] "GET / h l s −t e s t / o u t p u t /206 k . m3u8 HTTP / 1 . 1 " 200 893 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 6 : 2 5 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_2 . t s HTTP / 1 . 1 " 200 377692 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 6 : 2 6 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_3 . t s HTTP / 1 . 1 " 200 383520 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 6 : 2 6 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_4 . t s HTTP / 1 . 1 " 200 378444 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 6 : 2 6 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_5 . t s HTTP / 1 . 1 " 200 396116 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 6 : 2 6 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_6 . t s HTTP / 1 . 1 " 200 378632 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 6 : 3 2 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_7 . t s HTTP / 1 . 1 " 200 386904 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 1 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_8 . t s HTTP / 1 . 1 " 200 387280 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 1 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_9 . t s HTTP / 1 . 1 " 200 390288 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 6 : 3 2 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_7 . t s HTTP / 1 . 1 " 200 386904 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 1 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_10 . t s HTTP / 1 . 1 " 200 383332 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 1 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_11 . t s HTTP / 1 . 1 " 200 392168 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 1 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_12 . t s HTTP / 1 . 1 " 200 379572 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 1 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_13 . t s HTTP / 1 . 1 " 200 389724 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 1 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_14 . t s HTTP / 1 . 1 " 200 400440 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 1 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_15 . t s HTTP / 1 . 1 " 200 387092 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 1 −0200] "GET / h l s −t e s t / o u t p u t /206 k / fragment_16 . t s HTTP / 1 . 1 " 200 382016 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 1 −0200] "GET / h l s −t e s t / o u t p u t /728 k . m3u8 HTTP / 1 . 1 " 200 893 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 1 −0200] "GET / h l s −t e s t / o u t p u t /728 k / fragment_13 . t s HTTP / 1 . 1 " 200 1093220 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 2 −0200] "GET / h l s −t e s t / o u t p u t /728 k / fragment_14 . t s HTTP / 1 . 1 " 200 1126496 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 2 −0200] "GET / h l s −t e s t / o u t p u t /728 k / fragment_15 . t s HTTP / 1 . 1 " 200 1081000 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 2 −0200] "GET / h l s −t e s t / o u t p u t /728 k / fragment_16 . t s HTTP / 1 . 1 " 200 1034940 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 2 −0200] "GET / h l s −t e s t / o u t p u t /728 k / fragment_17 . t s HTTP / 1 . 1 " 200 1066712 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 7 : 5 3 −0200] "GET / h l s −t e s t / o u t p u t /728 k / fragment_18 . t s HTTP / 1 . 1 " 200 1062200 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 8 : 1 5 −0200] "GET / h l s −t e s t / o u t p u t /728 k / fragment_19 . t s HTTP / 1 . 1 " 200 1106004 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 8 : 1 5 −0200] "GET / h l s −t e s t / o u t p u t /728 k / fragment_20 . t s HTTP / 1 . 1 " 200 1100552 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 8 : 1 5 −0200] "GET / h l s −t e s t / o u t p u t /728 k / fragment_21 . t s HTTP / 1 . 1 " 200 1068968 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 8 : 1 9 −0200] "GET / h l s −t e s t / o u t p u t /728 k / fragment_22 . t s HTTP / 1 . 1 " 200 1104500 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 8 : 1 9 −0200] "GET / h l s −t e s t / o u t p u t /728 k / fragment_23 . t s HTTP / 1 . 1 " 200 884352 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 8 : 1 9 −0200] "GET / h l s −t e s t / o u t p u t /728 k / fragment_24 . t s HTTP / 1 . 1 " 200 1037760 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 8 : 2 1 −0200] "GET / h l s −t e s t / o u t p u t /728 k / fragment_25 . t s HTTP / 1 . 1 " 200 1049792 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 8 : 2 1 −0200] "GET / h l s −t e s t / o u t p u t /728 k / fragment_26 . t s HTTP / 1 . 1 " 200 306440 [ 1 2 / Nov / 2 0 1 1 : 2 0 : 2 8 : 2 1 −0200] "GET / h l s −t e s t / o u t p u t /728 k . m3u8 HTTP / 1 . 1 " 200 893

Sign up to vote on this title
UsefulNot useful