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