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

JEFFERSON RAFAEL KOZERSKI

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

Trabalho de Conclusão de Curso apresentado aoInstituto Superior Tupy - IST, como parte dos re-quisitos para a obtenção de grau de Bacharel deSistemas de Informação, sob a orientação da pro-fessora Edicarsia Barbiero Pillon.

Joinville

2011/2

JEFFERSON RAFAEL KOZERSKI

Trabalho de Diplomação sob o título Dis-tribuição De Vídeo Utilizando HTTP LiveStreaming, apresentado por Jefferson Ra-fael Kozerski, examinado e aprovado em08 de dezembro de 2011, em Joinville,dando ao seu autor o grau de Bacharel deSistemas de Informação, pela banca exa-minadora 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 meucaminho; à minha amada esposa Patrícia,pelo carinho, paciência, compreensão, in-centivo e dedicação para comigo duranteos anos de faculdade e, em especial nestafase 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 es-

forç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 devidoao número elevado de usuários consumindo streaming de mídias. A facilidade de conexãocom a rede mundial de computadores cresce exponencialmente a cada dia com a existência dedispositivos cada vez mais acessíveis e com a internet móvel sendo implantada em ritmo ace-lerado se comparado com a última década. Porém, mesmo que a facilidade de conexão tenhatornado possível à inserção de muitas novas pessoas à internet, sua capacidade de transfe-rência evoluiu de forma menos acentuada, juntamente com os dispositivos móveis, que em suamaioria, possuem processamento de dados limitados. As discrepâncias nas velocidades detransferências de dados entre conexões de internet móvel e conexões de banda larga criaramum desafio aos pesquisadores, que devem encontrar meios que possibilitem entregar arquivosde mídia a usuários finais com dispositivos que possuem processamentos de dados limitadosde forma satisfatória. Ou seja, sem interrupções e com a maior fidelidade de som e imagempossível aos usuários que se tornam mais exigente a cada dia. Entre os meios de distribuiçãode 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 seusutilizadores, entregando a eles, de forma diferenciada, os formatos de vídeo que melhor seadapte a ocasião. Desta forma, é possível entregar arquivos com qualidades satisfatórias aostelespectadores, diferenciando-os de acordo com capacidade dos seus dispositivos e velocida-des das suas conexões. Este trabalho propõe o estudo da tecnologia de streaming, bem comoentendimento da sua evolução durante a massiva disseminação da internet, a fim de conhecerseus métodos alternativos de distribuição, com foco em streaming adaptativo. Ainda, entenderalgumas das principais ferramentas de distribuição de streaming adaptativos presentes no mer-cado 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 docu-mentaçã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 deHTTP 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 aimplementaçã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 whoare 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 becomemore accessible and by way of the advent of mobile internet implementation at an accelera-ted rate as compared to the previous decade. However, even though connection facilities havemade it possible for many new people to be inserted into the internet, transfer capacity hasevolved much less accentuated, along with mobile devices, which mainly have limited data pro-cessing power. The discrepancies in data transfer speeds among mobile internet connectionsand broad band connections have created a challenge for researchers, who must find the meansto 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 andimage quality, in order to satisfy users who have become more and more demanding. The adap-tive streaming method is one of the streaming solutions currently employed. This method takesadvantage of varied connection speeds among users, delivering streaming to them at differentrates in the best video formats which adapt to each particular occasion. This way, it is possibleto delivery files at acceptable quality to the viewer and to stream to the devices based on thecapacity and speed of their particular connection. This paper proposes to study streaming tech-nology, as well as to understand the evolution during the massive internet dissemination, for thepurpose of discovering alternative transference methods, focused on adaptive streaming. Theresearch has also sought to understand the main adaptive streaming tools currently on the mar-ket. The HTTP Live Streaming distribution method has also been focused in this paper, whichis the first method for adaptive streaming distribution to be proposed as an official documentin RFC, for the purpose of making this a become a standard streaming distribution method. Afunctional prototype has been developed in this research paper, which is capable of applyingthe HTTP Live Streaming techniques for generating adaptive streaming , without any need ofmodifying distribution interfaces or capturing media, in order to decrease costs and facilitate theimplementation 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

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

−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 ar-

quivo de vídeo em um servidor web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

−Figura 5 Uma representação do funcionamento da entrega de HTTP streaming adap-

tativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

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

−Figura 7 Fluxograma do funcionamento da entrega de HTTP Live Streaming . . . . . . 41

−Figura 8 Exemplo de um arquivo .M3U8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

−Figura 9 Exemplo de um arquivo .M3U8 com variações de taxa de bits . . . . . . . . . . . . 44

−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

−Figura 13 Modelo da sintaxe genérica para FFmpeg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

−Figura 14 Modelo da sintaxe genérica para FFmpeg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

−Figura 15 Exemplo de um arquivo batch para a fragmentação de vídeo utilizando FFm-

peg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

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

−Figura 17 Arquivo mestre final, criado para utilizar os arquivos gerados pelo “PHP HLS

Fragmenter ” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

−Quadro 1 Comparação entre TCP and UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

−Quadro 2 Introdução do suporte de vídeo para HTML5 nos principais navegadores web 37

−Quadro 3 Suporte de vídeo HTML5 em alguns sites de vídeo de grandes publicações

(social e comercial) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

−Quadro 4 Atributos de identificação de URI para tag #EXT-X-STREAM-INF . . . . . . . . . . . 45

−Quadro 5 MIME type específico para cada extensão de arquivo . . . . . . . . . . . . . . . . . . . . . . 46

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

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

peg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 DISTRIBUIÇÃO DE VÍDEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

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

2.1.1 Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.1.2 Streaming Tradicional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.1.3 HTTP Progressive Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.1.4 HTTP streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2 HTTP STREAMING ADAPTATIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.3 CODECS E CONTÊINER PARA VÍDEO STREAMING ADAPTATIVO . . . . . . . . . 36

3 HTTP LIVE STREAMING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.1 CODIFICANDO ARQUIVOS DE VÍDEO COM FFMPEG . . . . . . . . . . . . . . . 49

4 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

APÊNDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

12

1 INTRODUÇÃO

É evidente que na era digital em que se está atualmente inserido, os métodos de comuni-

caçã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 visuali-

zar 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 dis-

tâ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 des-

carregamento 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 disponibili-

zação de áudio e vídeo.

Por outro lado, para algumas instituições de ensino, por exemplo, o processo de im-

plantaçã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 neces-

sidade 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 ce-

lulares, 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 Transfe-

rência de Hipertexto (HTTP), tem custo menor que os serviços de distribuição de mídias ofe-

recidos 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 é am-

plamente 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 protoco-

los. 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 atual-

mente vai além de somente computadores de mesa, chegando até aos dispositivos móveis

como celulares com hardwares extremamente pequenos e com processamentos limitados. Es-

tes 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 dis-

tribuiçã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 exis-

tência, em fase de desenvolvimento, de uma RFC1 proposta pela empresa Apple, com a finali-

dade de especificar e documentar a forma de distribuição de vídeos utilizando HTTP Live Stre-

aming (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 fer-

ramenta 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ân-

cia (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 stre-

aming 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 si-

nal 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úvi-

das 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á-

1RFCs (Request for Comments - pedido de comentários) são documentos padronizados pela Internet Enginee-ring Task Force (IETF), que tendem a ser detalhados e bastante técnicos, e descrevem padrões de cada protocoloda Internet (KUROSE; ROSS, 2010).

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 vi-

sã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ís-

ticas. 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, fa-

tores 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 Mo-

ving 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écni-

cas 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 fi-

tas 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 com-

pressã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 de-

senvolvimentos 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 Re-

alNetworks, 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 co-

dificador de áudio, um servidor de mídia e também um player1 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 de-

manda, 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 proto-

colos 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 desenvolvi-

mentos na área.

A partir do início da década de 2000, a penetração significativa da Internet nas resi-

dê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 ar-

mazenamento 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 de-

finitivo 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

1Tocadores de arquivos de áudio e vídeo

18

necessidades de autores, provedores de serviço e usuários finais (LIM; SINGER, 2006) (PAN-

SANATO, 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 strea-

ming. 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 armaze-

nado 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 hos-

pedou em um servidor na Internet, por exemplo, este processo de download se torna um pro-

cesso 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 visu-

aliza o conteúdo dos arquivos de áudio e vídeo de acordo com a quantidade do arquivo transfe-

rido. 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 dire-

tamente 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 trans-

missã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 águaFonte: 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).

2Quando citamos as palavras “em tempo real” sobre o assunto de distribuição de vídeo, significa que o clienterecebe um fluxo contínuo com um valor mínimo de atraso, onde a transmissão e recepção do conteúdo é quaseinstantânea (KOZAMERNIK, 2002).

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 Trans-

mission Control Protocol (TCP), melhor abordado no quadro 1:

Quadro 1: Comparação entre TCP and UDP

TCP UDPOrientado a conexão - uma conexão é cri-ada antes da transferência de dados.

Não orientado a conexão - não há neces-sidade de estabelecer uma conexão.

Confiável. Não confiável.Dois canais de comunicação, aumen-tando a interatividade entre o cliente e oservidor.

Unidirecional, sem interatividade, apenasiniciar e parar.

Correção de erros. Somente detecta os erros, faz uma verifi-cação dos dados - checksum.

Controle de fluxo. Gerencia a taxa dedownload.

Não possui controle de fluxo.

Reenvia pacotes perdidos. Não reenvia pacotes perdidos.Não predetermina taxa de entrega. OTCP irá aumentar a taxa de dados até quehaja perda de pacotes que indique con-gestionamento.

A taxa de entrega deve coincidir com ataxa de fluxo codificado. Diferentes codi-ficações para um mesmo conteúdo podeser necessário para ajustar diferentes ca-nais de entrega com taxa de entrega va-riável.

Tolerância de buffer overflow : se os da-dos chegarem rápido demais, o receptorenvia mensagem para o servidor para de-sacelerar o envio

Sem cache local - os pacotes são proces-sados pelo player multimídia conformesão recebidos

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ídiascontínuas ao mesmo tempo. Ele não costuma entregar os fluxos contínuos emsi, embora a intercalação do fluxo de mídia contínua com o fluxo de controleseja possível. Em outras palavras, RTSP age como um “controle remoto” paraservidores 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 descarrega-

mento, 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 ar-

quivos 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 absor-

ver 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 downloadFonte: 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 exe-

cuçã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 stre-

aming (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 Uni-

form 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 res-

posta HTTP, normalmente exibe para o utilizador uma barra demonstrando o buffer de carre-

gamento 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 GET / video .webm HTTP/ 1 . 12 Host : 127 .0 .0 .13 Connection : keep−a l i v e4 Referer : h t t p : / / 1 2 7 . 0 . 0 . 1 / v ideo .webm5 Range : bytes=0−

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

1 GET / video .webm HTTP/ 1 . 12 Host : 127 .0 .0 .13 Connection : keep−a l i v e4 Referer : h t t p : / / 1 2 7 . 0 . 0 . 1 / v ideo .webm5 Range : bytes=50422827−60636159

Figura 4: Exemplo de uma mensagem de requisição HTTP, por um fragmento de arquivo deví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 me-

lhor 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 strea-

ming.

Esses scripts, ao receberem uma requisição para descarregamento de um arquivo, ini-

ciam 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 codifica-

dos 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 exa-

tamente 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. Logica-

mente 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 local-

mente, 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 é ne-

cessá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 dis-

tribuição de conteúdos audiovisuais. Consecutivamente, fornecedores de conteúdo aceitaram

e vem difundindo amplamente a utilização de HTTP progressive download enquanto desenvol-

vem 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 re-

alizar 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 ins-

taladas 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 apro-

veitar 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 adota-

se 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 exem-

plo, 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 qua-

lidade, 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 adaptativoFonte: adaptado de Zambelli (2009, p. 8)

28

Pfeiffer (2010) descreve que recentemente o grupo MPEG vem trabalhando na padroni-

zação de uma especificação para HTTP streaming adaptativo, o qual eles nomearam de Dyna-

mic Adaptive Streaming for HTTP (DASH) na publicação do primeiro draft deste padrão de de-

senvolvimento 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, aproximada-

mente, 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 Appli-

cation 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 so-

luçõ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.

3As reuniões do grupo MPEG são numeradas em ordem crescente a cada novo evento que reúne o grupo4Mais detalhes estão acessíveis no endereço eletrônico mantido pelo grupo:

http://wiki.whatwg.org/wiki/Adaptive-Streaming

29

Para a criação do streaming adaptativo, o Smooth Streaming codifica, utilizando o apli-

cativo 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 dina-

micamente 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 “ma-

nifest” 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 ne-

cessá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 é ne-

cessá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 es-

pecí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 necessi-

dade 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 tecno-

logia 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 com-

pressã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 rea-

liza a codificação dos vídeos originais, o preparando para o distribuir posteriormente. Adobe

5http://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 distri-

buiçã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 disponi-

biliza 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 sincroni-

zaçã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 semelhante-

mente 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 Mes-

saging 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

6http://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 Framework7 (OSMF). Este framework possibilita

aos desenvolvedores criarem player de mídia personalizados, capaz de integrar outras exten-

sõ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 dispo-

ní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 desenvol-

7Mais 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 es-

pecí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 ser-

vidor, 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, tam-

bé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 adap-

tação bem como informações necessárias para a utilização do método adaptativo. No HTTP

8Um rascunho, pode ser uma apresentação individual ou uma apresentação do grupo de trabalho. Quando umrascunho é 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 distri-

buiçã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ísti-

cas 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 de-

finiçã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.

9Arquivo 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 pos-

suem o sistema operacional iOS10 versão 3.0 ou maior e em computadores com sistema ope-

racional 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 tecnolo-

gias incorporadas.

Pfeiffer (2010) cita ainda que, no desenvolvimento do HTML5, uma das principais espe-

cificaçõ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, possibi-

litando 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 pers-

pectiva, 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 possibi-

lidade 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 es-

pecificaçã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 operacio-

nal 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 pos-

sui um grande potencial, além de estar alinhado com as expectativas propostas neste trabalho.

10Sistema operacional para dispositivos móveis desenvolvido pela Apple11Sistema operacional para dispositivos móveis desenvolvido pela Google

36

1 < !DOCTYPE html>2 <head>3 < t i t l e >Exemplo de HTML5 Vídeo com arqu ivos a l t e r n a t i v o s < / t i t l e >4 <meta ht tp−equiv="Content-Type" content="text/html;charset=utf-8" / >5 < / head>6 <body>7 <video c o n t r o l s >8 <source src="video.mp4" type="video/mp4" / >9 <source src="video.webm" type="video/webm" / >

10 < / video>11 < / 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 conheci-

mentos 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 com-

ponentes separados: o CODEC, que é a abreviação união das palavras inglesas compressor-

decompressor (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, com-

posto pelos fluxos de mídia, informações sobre os dados e, em alguns casos, metadados. Con-

tê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 di-

reitos 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, sentiram-

se 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 comer-cial)

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 pro-

vedores 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 docu-

mentaçã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 aplica-

tivos 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 mol-

des 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 StreamingAdaptada de Apple (2011, p. 7)

Tem-se assim o ponto de partida para a compreensão a fim de aprofundar-se no funci-

onamento 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 indi-

viduais 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 #EXTM3U2 #EXT−X−TARGETDURATION:103 #EXT−X−MEDIA−SEQUENCE:04 #EXTINF:10 ,5 h t t p : / / midia . exemplo . com. br / segmento0 . t s6 #EXTINF:10 ,7 h t t p : / / midia . exemplo . com. br / segmento1 . t s8 #EXTINF:10 ,9 h t t p : / / midia . exemplo . com. br / segmento2 . t s

10 #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 posterior-

mente 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 adap-

tativo. 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 #EXTM3U2 #EXT−X−STREAM−INF :PROGRAM−ID =1 ,BANDWIDTH=12800003 h t t p : / / midia . exemplo . com. br / baixa_qual idade . m3u84 #EXT−X−STREAM−INF :PROGRAM−ID =1 ,BANDWIDTH=25600005 h t t p : / / midia . exemplo . com. br / media_qualidade . m3u86 #EXT−X−STREAM−INF :PROGRAM−ID =1 ,BANDWIDTH=76800007 h t t p : / / midia . exemplo . com. br / a l ta_qua l idade . 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 alternativosAdaptada 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 ValorBANDWIDTH Aceita como valor um número inteiro positivo, indicando a

maior taxa de bits por segundo dos fragmentos da play-list. Este valor é obrigatório para esta tag. Deve ser umlimite superior a taxa de bits dos fragmentos a fim de evitaroverhead.

PROGRAM-ID É um inteiro que identifica a apresentação dentro do escopode cada playlist. Este valor pode-se repetir a fim de identi-ficar playlists com diferentes codificações de taxa de bits.Sua presença não é obrigatória.

CODECS Contém valores, envolvidos por aspas (“”) e separados porvírgulas, de nomes de CODECs de mídia descritos deacordo com a ISO. Este parâmetro deve ser incluído nasdeclarações de #EXT-X-STREAM-INF.

RESOLUTION Indica um valor aproximado da resolução horizontal e ver-tical do vídeo presente no arquivo playlist. Sua declaraçãoé escrita por dois números inteiros separados pelo carac-tere “x”, onde o primeiro valor é equivalente a largura e osegundo a altura.

AUDIO Deve corresponder ao valor do parâmetro GRUPO-ID datag #EXT-X-MEDIA que possui valor “AUDIO” para atributoTYPE, indicando o conjunto de áudio que deve ser utilizadopara interpretação no momento da reprodução.

VIDEO Deve corresponder ao valor do parâmetro GRUPO-ID datag #EXT-X-MEDIA que possui valor “VIDEO” para atributoTYPE, indicando o conjunto de áudio que deve ser utilizadopara interpretação no momento da reprodução.

Quadro atapdato de Pantos (2011)

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 possibi-

litando 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 #EXTM3U

3 #EXT−X−STREAM−INF :PROGRAM−ID =1 ,BANDWIDTH=12800004 h t t p : / / midia . exemplo . com. br / baixa_qual idade . m3u85 #EXT−X−STREAM−INF :PROGRAM−ID =1 ,BANDWIDTH=12800006 h t t p : / / midia_backup . exemplo . com. br / baixa_qual idade . m3u8

8 #EXT−X−STREAM−INF :PROGRAM−ID =1 ,BANDWIDTH=25600009 h t t p : / / midia . exemplo . com. br / media_qualidade . m3u8

10 #EXT−X−STREAM−INF :PROGRAM−ID =1 ,BANDWIDTH=256000011 h t t p : / / midia_backup . exemplo . com. br / media_qualidade . m3u8

14 #EXT−X−STREAM−INF :PROGRAM−ID =1 ,BANDWIDTH=768000015 h t t p : / / midia . exemplo . com. br / a l ta_qua l idade . m3u816 #EXT−X−STREAM−INF :PROGRAM−ID =1 ,BANDWIDTH=768000017 h t t p : / / midia_backup . exemplo . com. br / a l ta_qua l idade . 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 MIME type.M3U8 application/x-mpegURL.ts 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 configu-

raçõ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 adi-

cionar 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 fragmen-

tos de mídia gerados pelo segmentador de HLS. A organização destes arquivos pode ser reali-

47

1 AddType a p p l i c a t i o n / x−mpegURL m3u82 AddType video /MP2T t s

Figura 12: Fragmento de uma arquivo “.htaccess” com as linhas de configuração para HTTPLive 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 co-

dificados 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 seg-

mentaçã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 qua-

lidade 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 ca-

pacidade, 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 escolhi-

dos 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 ge-

rado. 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 Resolução de tela Taxa de bits Keyframes Proporção de telaCelular 480 x 224 150 kpbs 30 16:9Celular 480 x 224 200 kpbs 45 16:9Celular 480 x 224 440 kpbs 90 16:9

Wifi 640 x 360 640 kpbs 90 16:9Wifi 640 x 360 1024 kpbs 90 16:9Wifi 960 x 540 1840 kpbs 90 16:9

Celular 480 x 300 150 kpbs 30 4:3Celular 480 x 300 200 kpbs 45 4:3Celular 480 x 300 440 kpbs 90 4:3

Wifi 640 x 480 640 kpbs 90 4:3Wifi 1280 x 960 4540 kpbs 90 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 alter-

nativo, 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 uti-

lizaçã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, escolheu-

se 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 bene-

ficiar 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 apli-

caçã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 inclu-

1Mais informações sobre licenças do FFmpeg podem ser visualizadas na página de Considerações Legais doprojeto: http://ffmpeg.org/legal.html

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 loba is ] [ [ opções do arqu ivo de entrada ] [ ’-i’ ’arquivo deentrada’ ] ] . . . { [ opções do arqu ivo 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 com-

pressã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 cone-

xõ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 mo-

delos 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 for-

mato “.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

2Compilação 8475ec13A 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 Detalhes-i -i VideoOriginal.avi Informa o caminho físico do arquivo original a ser

utilizado-ss -ss 0 Busca uma determinada posição de tempo e utiliza

como ponto inicial do vídeo, ignorando o espaço detempo anterior, dentro do arquivo de entrada. Casosua declaração seja feita nas opções do arquivo desaída, essa posição é obtida do arquivo codificadoe, como consequência, possui uma maior precisão.Seu valor pode ser um numero inteiro ou de pontoflutuante, indicando os segundos, ou um valor detexto com padrão “hh:mm:ss[.xxx]”

-t -t 10 Indica que o aplicativo deve parar de escrever oarquivo de saída após alcançar o valor de tempodefinido nesse atributo. Seu valor pode ser umnumero inteiro ou de ponto flutuante, indicandoos segundos, ou um valor de texto com padrão“hh:mm:ss[.xxx]”

-s -s 480x300 Define o tamanho da resolução-aspect -aspect 4:3 Define a proporção de tela (aspect ratio)-b -b 64k

-b:v 64k-b:a 64k

Define a taxa de bits a ser utilizada. Pode ser de-clarada acompanhando as letras específicas paraespecificar qual mídia deseja-se atribuir o valor.(:v refere-se a vídeo e :a refere-se a áudio)

-bufsize -bufsize 200k Define o tamanho do buffer de vídeo (em bits)-maxrate -maxrate 200k 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

-r -r 24 Define a taxa de quadros por segundo (fps).-bt -bt 200k Define a tolerância da taxa de bits (padrão 4000k).

Este valor define quão longe a taxa de controlepode desviar da taxa de bits média.

-ar -ar 48000 Define a frequência do áudio (Hz)-qmax -qmax 63 Define a taxa máxima da escala do quantizador

(VBR) do vídeo (bit/s)-qmin -qmin 8 Define a taxa mínima da escala do quantizador

(VBR) do vídeo (bit/s)-vcodec -vcodec libx264 Define CODEC de vídeo a ser utilizado-acodec -acodec libvorbis Define CODEC de áudio a ser utilizado-f -f mpegts Entende-se como forçar o formato de entrada ou

saída. Normalmente, o formato é detectado auto-maticamente, o que torna essa opção desneces-sária na maioria dos casos

Adaptado a partir de (FFMPEG, 2011)

52

1 ffmpeg . exe − i exemplo_or ig ina l . av i −s 640x360 −b : v 1250k −qmax 63 −b : a 56k −ar 22050 −acodec l i b v o r b i s −vcodec l i bx264 exemplo_convert ido . 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é en-

tã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 neces-

sidade 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 @echo o f f2 ffmpeg . exe −y −ss 0 −t 10 − i "exemplo_original.avi" −vcodec l i bx264 −

acodec libmp3lame −s 400x224 −aspect 16:9 −qmax 51 −qmin 10 −maxrate 728k−bu fs i ze 728k −b : a 128k −b : v 728k −ar 32000 −bt 728k −r 10 −f mpegts −p a r t i t i o n s + pa r t i 4x4 +partp8x8+partb8x8 "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 execu-

tado, 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 Apa-

che 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 play-

list 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 Fragmen-

ter ”. 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 ca-

minho 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 al-

gumas 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 Fragmen-

ter ”. 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 frag-

mentos 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 #EXTM3U2 #EXT−X−STREAM−INF :PROGRAM−ID =1 ,BANDWIDTH=12800003 88k . m3u84 #EXT−X−STREAM−INF :PROGRAM−ID =1 ,BANDWIDTH=25600005 206k . m3u86 #EXT−X−STREAM−INF :PROGRAM−ID =1 ,BANDWIDTH=76800007 728k . m3u8

Figura 17: Arquivo mestre final, criado para utilizar os arquivos gerados pelo “PHP HLS Frag-menter ”

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, é pre-

ciso 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 rea-

lizado 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 compo-

nente 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 Adap-

tativo, 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 adapta-

bilidade 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, desen-

volvida 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 distri-

buiçã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 Progres-

sive 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 Strea-

ming, 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. Em-

bora 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 ne-

cessá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 em-

presa 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 in-

serçã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 distri-

buiçã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 deInformaçã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 AdaptationAlgorithms in Adaptive Streaming over HTTP. 2011. Multimedia Systems Conference, SanJose, California, USA, February, 2011.

APPLE, I. HTTP Live Streaming Overview. 2011. Disponível em: <http://goo.gl/f8jV8>. Acessoem: 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 VideoEncoding Technique for Mobile Internet-based Vision. 2010. Part of LECTURE NOTES INCOMPUTER SCIENCE vol.5960 - Mobile Multimedia Processing Fundamentals, Methods, andApplications.

BRYANT, S. Videoblogging for Dummies. [S.l.]: John Wiley & Sons, 2006. (For Dummies). ISBN9780471971771.

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 andCommunication 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 forIntegrating 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). ISBN9781430224273.

MANZATO, M. G. Técnicas e Padrões de Codificação de Vídeo. 2006. Trabalho de Conclusãode Curso (Bacharel em Ciência da Computação) - Departamento de Computação, UniversidadeEstadual de Londrina, Londrina, PR, 2004.

MICROSOFT, C. Smooth Streaming. 2011. Disponível em: <http://goo.gl/BQX89>. Acessoem: 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>. Acessoem: 16 de out. de 2011.

PANSANATO, G. C. Análise detalhada de CODECS e estudos relacionados. 2005. Relatóriode Estágio Curricular (Bacharelado em Ciência da Computação) - Universidade Estadual deLondrina, 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 GuideSeries). 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 NextGeneration 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ÇOESCORPORATIVAS. 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 educationaldevelopment. 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 MediaLLC., 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 <?php

3 require_once ("getid3/getid3.php" ) ;

5 c lass FFmpeg_HLS_conversion_test {

7 var $FFmpeg_path = NULL;

8 var $output_path = "output" ;

9 var $ input_path = "input" ;

10 var $ l o g _ f i l e = "./log_conversion.log" ;

11 var $ i n p u t _ f i l e = NULL;

13 var $parameters = NULL;

14 var $secondsFragment = 10;

15 var $ u s e _ t h i s _ p r o f i l e = NULL;

17 var $ T h i s F i l e I n f o = NULL;

19 var $getID3 = NULL;

21 / / op t ion "−y "

22 / / 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 to f i lename

23 var $ o v e r w r i t e _ f i l e s = TRUE ;

24 var $pref ix_segments = "fragment_" ;

25 var $ p l a y l i s t _ o u t = "playlist.m3u8" ;

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

28 "mobile_16x9_128k" => Array (

29 "-vcodec" => "libx264"

30 ,"-acodec" => "libmp3lame"

31 ,"-s" => "400x224"

32 ,"-aspect" => "16:9"

33 ,"-qmax" => 51

34 ,"-qmin" => 10

35 ,"-maxrate" => "88k"

36 ,"-bufsize" => "88k"

37 ,"-b:a" => "32k"

38 ,"-b:v" => "88k"

39 ,"-ar" => 32000

40 ,"-t" => 10

41 ,"-bt" => "88k"

42 ,"-r" => 10

43 ,"-f" => "mpegts"

44 ,"-partitions" => "+parti4x4+partp8x8+partb8x8"

45 )

46 ,"mobile_16x9_256k" => Array (

47 "-vcodec" => "libx264"

48 ,"-acodec" => "libmp3lame"

49 ,"-s" => "400x224"

50 ,"-aspect" => "16:9"

51 ,"-qmax" => 51

52 ,"-qmin" => 10

53 ,"-maxrate" => "206k"

64

54 ,"-bufsize" => "206k"

55 ,"-b:a" => "88k"

56 ,"-b:v" => "206k"

57 ,"-ar" => 32000

58 ,"-t" => 10

59 ,"-bt" => "206k"

60 ,"-r" => 10

61 ,"-f" => "mpegts"

62 ,"-partitions" => "+parti4x4+partp8x8+partb8x8"

63 )

64 ,"mobile_16x9_768k" => Array (

65 "-vcodec" => "libx264"

66 ,"-acodec" => "libmp3lame"

67 ,"-s" => "400x224"

68 ,"-aspect" => "16:9"

69 ,"-qmax" => 51

70 ,"-qmin" => 10

71 ,"-maxrate" => "728k"

72 ,"-bufsize" => "728k"

73 ,"-b:a" => "128k"

74 ,"-b:v" => "728k"

75 ,"-ar" => 32000

76 ,"-t" => 10

77 ,"-bt" => "728k"

78 ,"-r" => 10

79 ,"-f" => "mpegts"

80 ,"-partitions" => "+parti4x4+partp8x8+partb8x8"

81 )

82 ) ;

83 / / $ o r i g i n a l _ f i l e n a m e s t r i n g f i lename or f u l l p a t h + f i lename

84 / / $use_p ro f i l e bool or s t r i n g name of e x i s t i n g p r o f i l e , or FALSE to does not use

p r o f i l e

85 / / $parameters Array a d d i t i o n a l parameters

86 f u n c t i o n __const ruc t ( $o r i g i na l_ f i l ename , $use_p ro f i l e = FALSE, $parameters = Array ( ) ) {

87 $ th is−>updatePaths ( ) ;

88 $ th is−>set_PathFFmpeg ( ) ;

90 $ th is−>getID3 = new getID3 ;

92 i f ( i s _ f i l e ( $ o r i g i n a l _ f i l e n a m e ) ) {

93 $ th is−>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 ) ;

94 } else i f ( i s _ f i l e ( $ th i s−>input_path . $ o r i g i n a l _ f i l e n a m e ) ) {

95 $ th is−>s e t _ I n p u t F i l e ( $ th i s−>input_path . $ o r i g i n a l _ f i l e n a m e ) ;

96 }

97 i f ( isset ( $parameters ) && is_array ( $parameters ) && count ( $parameters ) >0) {

98 foreach ( $parameters as $param => $value ) {

99 $ th is−>add_parameter ( $param , $value ) ;

100 }

101 }

103 i f ( $use_p ro f i l e !== FALSE) {

104 i f ( ! $ th i s−>s e t _ P r o f i l e ( $use_p ro f i l e ) ) {

105 i f ( ! isset ( $ th i s−>parameters ) ) {

106 $ th is−>w r i t e _ l o g ("Pameter and Profile Not Found!" ) ;

65

107 ex i t ( ) ;

108 }

109 }

110 }

111 $ th is−>g e t _ I n f o I n p u t F i l e ( ) ;

112 }

114 f u n c t i o n set_PathFFmpeg ( $ f u l l P a t h = ’’ ) {

115 i f ( $ f u l l P a t h != ’’ ) {

116 i f ( i s _ f i l e ( $ f u l l P a t h ) ) {

117 $ th is−>FFmpeg_path = $ f u l l P a t h ;

118 } else {

119 $ th is−>w r i t e _ l o g ("FFmpeg file Not Found!" ) ;

120 ex i t ( ) ;

121 }

122 } else {

123 $ th is−>FFmpeg_path = getcwd ( ) .DIRECTORY_SEPARATOR. "ffmpeg.exe" ;

124 }

125 }

127 / / TODO: improve t h i s f u n c t i o n : /

128 f u n c t i o n updatePaths ( ) {

129 $ th is−>output_path = getcwd ( ) .DIRECTORY_SEPARATOR. $ th is−>output_path .DIRECTORY_SEPARATOR;

130 $ th is−>input_path = getcwd ( ) .DIRECTORY_SEPARATOR. $ th is−>input_path .DIRECTORY_SEPARATOR;

131 }

133 / / $param s t r i n g

134 / / $value s t r i n g

135 f u n c t i o n add_parameter ( $param , $value ) {

136 i f ( $param == "-t" ) {

137 $ th is−>set_secondsFragment ( $value ) ;

138 } else i f ( $param != "-ss" && $param != "" ) {

139 $ th is−>parameters [ $param ] = $value ;

140 }

141 }

143 / / $ i n p u t F i l e s t r i n g f i lename or f u l l p a t h + f i lename

144 f u n c t i o n s e t _ I n p u t F i l e ( $ i n p u t F i l e ) {

145 $ th is−>i n p u t _ f i l e = $ i n p u t F i l e ;

146 }

148 f u n c t i o n s e t _ P l a y L i s t F i l e ( $ P l a y L i s t F i l e ) {

149 $ th is−>p l a y l i s t _ o u t = $ P l a y L i s t F i l e ;

150 }

152 f u n c t i o n set_secondsFragment ( $secondsFragment ) {

153 $ th is−>secondsFragment = $secondsFragment ;

154 }

156 / / $prof i leName s t r i n g p r o f i l e name

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

159 i f ( isset ( $ th i s−>p r o f i l e s [ $prof i leName ] ) ) {

160 $ th is−>u s e _ t h i s _ p r o f i l e = $prof i leName ;

66

161 i f ( is_array ( $ th i s−>p r o f i l e s [ $prof i leName ] ) && count ( $ th i s−>p r o f i l e s [ $prof i leName ] ) >0) {

162 foreach ( $ th i s−>p r o f i l e s [ $prof i leName ] as $Prof i leParam => $Prof i leParamValue ) {

163 / / do not ove rwr i t e

164 i f ( ! isset ( $ th i s−>parameters [ $Prof i leParam ] ) ) {

165 $ th is−>add_parameter ( $Prof i leParam , $Prof i leParamValue ) ;

166 }

167 }

168 }

169 r e t u r n TRUE ;

170 } else {

171 r e t u r n FALSE ;

172 }

173 }

175 f u n c t i o n get_CommandLineWithParameters ( ) {

176 $cmd = " " ;

177 i f ( isset ( $ th i s−>parameters ) && is_array ( $ th i s−>parameters ) && count ( $ th i s−>parameters ) >0) {

178 foreach ( $ th i s−>parameters as $parameter => $value ) {

179 $cmd .= $parameter . " " . $value . " " ;

180 }

181 }

182 r e t u r n $cmd ;

183 }

185 f u n c t i o n make_HeaderPlayl ist ( ) {

187 $str_header = "#EXTM3U\n" ;

188 i f ( isset ( $ th i s−>secondsFragment ) && $th is−>secondsFragment != "" ) {

189 $str_header .= "#EXT-X-TARGETDURATION:" . $ th i s−>secondsFragment . "\n" ;

190 } else {

191 $ th is−>w r i t e _ l o g ("FragmentTime (TARGETDURATION) property Not Found!" ) ;

192 ex i t ( ) ;

193 }

194 $str_header .= "#EXT-X-MEDIA-SEQUENCE:0\n" ;

195 i f ( i s _ f i l e ( $ th i s−>p l a y l i s t _ o u t ) ) {

196 i f ( $ th i s−>o v e r w r i t e _ f i l e s === FALSE) {

197 $now = time ( ) ;

198 $ th is−>p l a y l i s t _ o u t = $now . "_" . $ th i s−>p l a y l i s t _ o u t ;

199 } else {

200 u n l i n k ( $ th i s−>p l a y l i s t _ o u t ) ;

201 }

202 }

203 $ th is−>w r i t e _ P l a y l i s t ( $str_header ) ;

204 }

205 f u n c t i o n make_FragmentPlayl ist ( $time , $name) {

206 $ s t r = "#EXTINF:" . $t ime . ",\n" ;

207 $ s t r .= $name . "\n" ;

208 $ th is−>w r i t e _ P l a y l i s t ( $ s t r ) ;

209 }

210 f u n c t i o n make_EndPlayl ist ( ) {

211 $ s t r = "#EXT-X-ENDLIST" ;

212 $ th is−>w r i t e _ P l a y l i s t ( $ s t r ) ;

213 }

67

215 f u n c t i o n create_segments ( ) {

216 $command_line = "\"" . $ th i s−>FFmpeg_path . "\"" ;

217 i f ( $ th i s−>o v e r w r i t e _ f i l e s ) {

218 $command_line .= " -y " ;

219 }

220 $command_l ine_input_f i le .= " -i \"" . $ th i s−>i n p u t _ f i l e . "\" " ;

221 $params = $th is−>get_CommandLineWithParameters ( ) ;

222 i f ( isset ( $ th i s−>T h i s F i l e I n f o [ ’playtime_seconds’ ] ) ) {

223 $time = $ th is−>T h i s F i l e I n f o [ ’playtime_seconds’ ] ;

225 / / adjustment f o r "Maximum execut ion t ime " on PHP s c r i p t

226 set_t ime_l imit ( $t ime ∗2.3) ;

229 $f ragments_ in tegers = f loor ( ( $time−$ las t_ f ragment ) / $ th i s−>secondsFragment ) ;

230 $ las t_ f ragment = c e i l ( $time−($ f ragments_ in tegers ∗ $ th is−>secondsFragment ) ) ;

231 i f ( $ las t_ f ragment == 0) {

232 $ las t_ f ragment = FALSE ;

233 }

235 $path_out = $ th is−>output_path ;

236 $ p l a y l i s t _ o u t = $ th is−>output_path ;

237 i f ( isset ( $ th i s−>parameters [ "-maxrate" ] ) && $th is−>parameters [ "-maxrate" ] != "" ) {

238 $ p l a y l i s t _ o u t .= $ th is−>parameters [ "-maxrate" ] . ".m3u8" ;

239 $ f ragment_ou t_ re la t i ve = $ th is−>parameters [ ’-maxrate’ ] . DIRECTORY_SEPARATOR;

240 } else {

241 $ th is−>w r i t e _ l o g ("FragmentTime (TARGETDURATION) property Not Found!" ) ;

242 ex i t ( ) ;

243 }

244 i f ( ! i s_d i r ( $path_out .DIRECTORY_SEPARATOR. $ f ragment_ou t_ re la t i ve ) ) {

245 i f ( mkdir ( $path_out .DIRECTORY_SEPARATOR. $ f ragment_ou t_ re la t i ve , 775 , TRUE) ) {

246 $ th is−>w r i t e _ l o g ("Creating path out! (" . $path_out .DIRECTORY_SEPARATOR.

$ f ragment_ou t_ re la t i ve . ")" ) ;

247 } else {

248 $ th is−>w r i t e _ l o g ("Error on create path out! (" . $path_out .DIRECTORY_SEPARATOR.

$ f ragment_ou t_ re la t i ve . ")" ) ;

249 }

250 }

251 / / se t P l a y l i s t name

252 $ th is−>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 ) ;

253 / / c rea te p l a y l i s t f i l e

254 $ th is−>make_HeaderPlayl ist ( ) ;

256 i f ( ! is_wr i table ( $path_out .DIRECTORY_SEPARATOR. $ f ragment_ou t_ re la t i ve ) ) {

257 $ th is−>w r i t e _ l o g ("Path Out is not writable! (" . $path_out .DIRECTORY_SEPARATOR.

$ f ragment_ou t_ re la t i ve . ")" ) ;

258 ex i t ( ) ;

259 }

260 $now = time ( ) ;

261 $timeSeconds = 0;

262 for ( $currentFragment = 1 ; $currentFragment <=$f ragments_ in tegers ; $currentFragment ++) {

263 $fragment = $ f ragmen t_ou t_ re la t i ve . "" . $ th i s−>pref ix_segments . $currentFragment . ".ts" ;

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

68

266 $fragment = $ f ragmen t_ou t_ re la t i ve . $ th i s−>pref ix_segments . "_" . $now . "_" .

$currentFragment . ".ts" ;

267 f i l e _ p u t _ c o n t e n t s ("exec_temp.cmd" , $command_line . " -ss " . $timeSeconds . " -t " . $ th i s

−>secondsFragment . " " . $command_l ine_input_f i le . " " . $params . " \"" . $path_out .

$fragment . "\"" ) ;

268 passthru ("exec_temp.cmd" ) ;

269 $ th is−>w r i t e _ l o g ("Creating fragment: (\"" . $path_out . $fragment . "\") " ) ;

270 } else {

271 f i l e _ p u t _ c o n t e n t s ("exec_temp.cmd" , $command_line . " -ss " . $timeSeconds . " -t " . $ th i s

−>secondsFragment . " " . $command_l ine_input_f i le . " " . $params . " \"" . $path_out .

$fragment . "\"" ) ;

272 passthru ("exec_temp.cmd" ) ;

273 $ th is−>w r i t e _ l o g ("Creating fragment: (\"" . $path_out . $fragment . "\") " ) ;

274 }

275 / / add segment to p l a y l i s t

276 $ th is−>make_FragmentPlayl ist ( $ th is−>secondsFragment , s t r _ rep lace ("\\" ,"/" , $fragment ) ) ;

277 $timeSeconds = $currentFragment ∗ $ th is−>secondsFragment ;

278 }

279 i f ( $ las t_ f ragment !== FALSE) {

280 $fragment = $ f ragmen t_ou t_ re la t i ve . "" . $ th i s−>pref ix_segments . $currentFragment . ".ts" ;

281 i f ( i s _ f i l e ( $path_out . "" . $ th i s−>pref ix_segments . $currentFragment . ".ts" ) && $th is−>

o v e r w r i t e _ f i l e s === FALSE) {

282 $fragment = $ f ragmen t_ou t_ re la t i ve . $ th i s−>pref ix_segments . "_" . $now . "_" .

$currentFragment . ".ts" ;

283 f i l e _ p u t _ c o n t e n t s ("exec_temp.cmd" , $command_line . " -ss " . $timeSeconds . " -t " .

$ las t_ f ragment . " " . $command_l ine_input_f i le . " " . $params . " \"" . $path_out . "" .

$fragment . "\"" ) ;

285 passthru ("exec_temp.cmd" ) ;

286 $ th is−>w r i t e _ l o g ("Creating fragment: (" . $path_out . $fragment . ") " ) ;

288 } else {

289 f i l e _ p u t _ c o n t e n t s ("exec_temp.cmd" , $command_line . " -ss " . $timeSeconds . " -t " .

$ las t_ f ragment . " " . $command_l ine_input_f i le . " " . $params . " \"" . $path_out . "" .

$fragment . "\"" ) ;

291 passthru ("exec_temp.cmd" ) ;

292 $ th is−>w r i t e _ l o g ("Creating fragment: (" . $path_out . $fragment . ") " ) ;

293 }

294 / / add segment to p l a y l i s t

295 $ th is−>make_FragmentPlayl ist ( $ last_ f ragment , s t r _ rep lace ("\\" ,"/" , $fragment ) ) ;

296 }

297 / / end p l a y l i s t f i l e

298 $ th is−>make_EndPlayl ist ( ) ;

299 } else {

300 $ th is−>w r i t e _ l o g ("playtime_seconds ID3 property Not Found!" ) ;

301 ex i t ( ) ;

302 }

303 }

305 / / $ f i l e == f u l l path + f i lename & extens ion

306 f u n c t i o n g e t _ I n f o I n p u t F i l e ( ) {

307 $ th is−>T h i s F i l e I n f o = $ th is−>getID3−>analyze ( $ th is−>i n p u t _ f i l e ) ;

308 }

69

310 f u n c t i o n w r i t e _ l o g ($msg) {

311 $msg = "\nLog (" . date (’Y-m-d H:i:s’ ) . ") : " . $msg ;

312 f i l e _ p u t _ c o n t e n t s ( $ th i s−>l o g _ f i l e , $msg , FILE_APPEND) ;

313 }

314 f u n c t i o n w r i t e _ P l a y l i s t ($msg) {

315 f i l e _ p u t _ c o n t e n t s ( $ th i s−>p l a y l i s t _ o u t , utf8_encode ($msg) , FILE_APPEND) ;

316 }

317 }

APÊNDICE B - SCRIPT PHP PARA CHAMADA A BIBLIOTECA PHP HLS FRAGMEN-

TER

1 <?php

2 include "includes/ffmpeg_HLS_conversion.php" ;

4 $conversion = New FFmpeg_HLS_conversion_test ("exemplo_original.avi" , ’mobile_16x9_128k’ ) ;

5 $conversion−>create_segments ( ) ;

7 $conversion = New FFmpeg_HLS_conversion_test ("exemplo_original.avi" , ’mobile_16x9_256k’ ) ;

8 $conversion−>create_segments ( ) ;

10 $conversion = New FFmpeg_HLS_conversion_test ("exemplo_original.avi" , ’mobile_16x9_768k’ ) ;

11 $conversion−>create_segments ( ) ;

13 ?>

APÊNDICE C - CÓDIGO HTML5 CONTENDO CHAMADAS AO ARQUIVO DE ÍNDICE

HLS

1 <html>

2 <head>

3 < t i t l e >Test< / t i t l e >

4 <meta name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable

=0;" / >

5 < / head>

6 <body sty le="background-color:#FFFFFF; ">

7 <center>

8 <video src="indexFile.m3u8" c o n t r o l s autop lay >< / video>

9 < / center>

10 < / body>

11 < / html>

70

APÊNDICE D - FRAGMENTO DE LOG DO APACHE CONTENDO O HISTÓRICO DE

REQUISIÇÕES AOS ARQUIVOS DE ÍNDICE E FRAGMENTOS

1 [ 1 2 / Nov /2011:20:26:19 −0200] "GET / hls−t e s t / ou tput / HTTP/ 1 . 1 " 200 286

2 [ 1 2 / Nov /2011:20:26:20 −0200] "GET / hls−t e s t / ou tput / i n d e x F i l e . m3u8 HTTP/ 1 . 1 " 206 2

3 [ 1 2 / Nov /2011:20:26:20 −0200] "GET / hls−t e s t / ou tput / i n d e x F i l e . m3u8 HTTP/ 1 . 1 " 206 189

4 [ 1 2 / Nov /2011:20:26:21 −0200] "GET / hls−t e s t / ou tput /88 k . m3u8 HTTP/ 1 . 1 " 200 867

5 [ 1 2 / Nov /2011:20:26:21 −0200] "GET / hls−t e s t / ou tput /88 k / fragment_1 . t s HTTP/ 1 . 1 " 200 155852

6 [ 1 2 / Nov /2011:20:26:21 −0200] "GET / hls−t e s t / ou tput /88 k / fragment_2 . t s HTTP/ 1 . 1 " 200 168824

7 [ 1 2 / Nov /2011:20:26:23 −0200] "GET / hls−t e s t / ou tput /88 k / fragment_3 . t s HTTP/ 1 . 1 " 200 168448

8 [ 1 2 / Nov /2011:20:26:25 −0200] "GET / hls−t e s t / ou tput /206 k . m3u8 HTTP/ 1 . 1 " 200 893

9 [ 1 2 / Nov /2011:20:26:25 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_2 . t s HTTP/ 1 . 1 " 200 377692

10 [ 1 2 / Nov /2011:20:26:26 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_3 . t s HTTP/ 1 . 1 " 200 383520

11 [ 1 2 / Nov /2011:20:26:26 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_4 . t s HTTP/ 1 . 1 " 200 378444

12 [ 1 2 / Nov /2011:20:26:26 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_5 . t s HTTP/ 1 . 1 " 200 396116

13 [ 1 2 / Nov /2011:20:26:26 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_6 . t s HTTP/ 1 . 1 " 200 378632

14 [ 1 2 / Nov /2011:20:26:32 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_7 . t s HTTP/ 1 . 1 " 200 386904

15 [ 1 2 / Nov /2011:20:27:51 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_8 . t s HTTP/ 1 . 1 " 200 387280

16 [ 1 2 / Nov /2011:20:27:51 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_9 . t s HTTP/ 1 . 1 " 200 390288

17 [ 1 2 / Nov /2011:20:26:32 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_7 . t s HTTP/ 1 . 1 " 200 386904

18 [ 1 2 / Nov /2011:20:27:51 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_10 . t s HTTP/ 1 . 1 " 200 383332

19 [ 1 2 / Nov /2011:20:27:51 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_11 . t s HTTP/ 1 . 1 " 200 392168

20 [ 1 2 / Nov /2011:20:27:51 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_12 . t s HTTP/ 1 . 1 " 200 379572

21 [ 1 2 / Nov /2011:20:27:51 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_13 . t s HTTP/ 1 . 1 " 200 389724

22 [ 1 2 / Nov /2011:20:27:51 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_14 . t s HTTP/ 1 . 1 " 200 400440

23 [ 1 2 / Nov /2011:20:27:51 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_15 . t s HTTP/ 1 . 1 " 200 387092

24 [ 1 2 / Nov /2011:20:27:51 −0200] "GET / hls−t e s t / ou tput /206 k / fragment_16 . t s HTTP/ 1 . 1 " 200 382016

25 [ 1 2 / Nov /2011:20:27:51 −0200] "GET / hls−t e s t / ou tput /728 k . m3u8 HTTP/ 1 . 1 " 200 893

26 [ 1 2 / Nov /2011:20:27:51 −0200] "GET / hls−t e s t / ou tput /728 k / fragment_13 . t s HTTP/ 1 . 1 " 200 1093220

27 [ 1 2 / Nov /2011:20:27:52 −0200] "GET / hls−t e s t / ou tput /728 k / fragment_14 . t s HTTP/ 1 . 1 " 200 1126496

28 [ 1 2 / Nov /2011:20:27:52 −0200] "GET / hls−t e s t / ou tput /728 k / fragment_15 . t s HTTP/ 1 . 1 " 200 1081000

29 [ 1 2 / Nov /2011:20:27:52 −0200] "GET / hls−t e s t / ou tput /728 k / fragment_16 . t s HTTP/ 1 . 1 " 200 1034940

30 [ 1 2 / Nov /2011:20:27:52 −0200] "GET / hls−t e s t / ou tput /728 k / fragment_17 . t s HTTP/ 1 . 1 " 200 1066712

31 [ 1 2 / Nov /2011:20:27:53 −0200] "GET / hls−t e s t / ou tput /728 k / fragment_18 . t s HTTP/ 1 . 1 " 200 1062200

32 [ 1 2 / Nov /2011:20:28:15 −0200] "GET / hls−t e s t / ou tput /728 k / fragment_19 . t s HTTP/ 1 . 1 " 200 1106004

33 [ 1 2 / Nov /2011:20:28:15 −0200] "GET / hls−t e s t / ou tput /728 k / fragment_20 . t s HTTP/ 1 . 1 " 200 1100552

34 [ 1 2 / Nov /2011:20:28:15 −0200] "GET / hls−t e s t / ou tput /728 k / fragment_21 . t s HTTP/ 1 . 1 " 200 1068968

35 [ 1 2 / Nov /2011:20:28:19 −0200] "GET / hls−t e s t / ou tput /728 k / fragment_22 . t s HTTP/ 1 . 1 " 200 1104500

36 [ 1 2 / Nov /2011:20:28:19 −0200] "GET / hls−t e s t / ou tput /728 k / fragment_23 . t s HTTP/ 1 . 1 " 200 884352

37 [ 1 2 / Nov /2011:20:28:19 −0200] "GET / hls−t e s t / ou tput /728 k / fragment_24 . t s HTTP/ 1 . 1 " 200 1037760

38 [ 1 2 / Nov /2011:20:28:21 −0200] "GET / hls−t e s t / ou tput /728 k / fragment_25 . t s HTTP/ 1 . 1 " 200 1049792

39 [ 1 2 / Nov /2011:20:28:21 −0200] "GET / hls−t e s t / ou tput /728 k / fragment_26 . t s HTTP/ 1 . 1 " 200 306440

40 [ 1 2 / Nov /2011:20:28:21 −0200] "GET / hls−t e s t / ou tput /728 k . m3u8 HTTP/ 1 . 1 " 200 893