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

Jefferson Rafael Kozerski DISTRIBUIO DE VDEO UTILIZANDO HTTP LIVE STREAMING

Joinville 2011/2

J EFFERSON R AFAEL KOZERSKI

Distribuio De Vdeo Utilizando HTTP Live Streaming

Trabalho de Concluso de Curso apresentado ao Instituto Superior Tupy - IST, como parte dos requisitos para a obteno de grau de Bacharel de Sistemas de Informao, sob a orientao da professora Edicarsia Barbiero Pillon.

Joinville 2011/2

J EFFERSON R AFAEL KOZERSKI

Trabalho de Diplomao sob o ttulo Distribuio De Vdeo Utilizando HTTP Live Streaming, apresentado por Jefferson Rafael Kozerski, examinado e aprovado em 08 de dezembro de 2011, em Joinville, dando ao seu autor o grau de Bacharel de Sistemas de Informao, pela banca examinadora constituda conforme abaixo:

MSc. Edicarsia Barbiero Pillon - SOCIESC

MSc. Paulo Marcondes Bouseld - SOCIESC

Esp. Claudinei Dias - SOCIESC

Primeiramente dedico este trabalho Deus, que me deu foras e iluminou meu caminho; minha amada esposa Patrcia, pelo carinho, pacincia, compreenso, incentivo e dedicao para comigo durante os anos de faculdade e, em especial nesta fase nal.

AGRADECIMENTO

A Deus, por sua eterna bondade e ter tornado possvel essa realizao. 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 esforo, dedicao, no existe meio termo. Ou voc faz uma coisa bem-feita ou no faz. Ayrton Senna

RESUMO A internet hoje est experimentando um grande crescimento na quantidade de trfego devido ao nmero elevado de usurios consumindo streaming de mdias. A facilidade de conexo com a rede mundial de computadores cresce exponencialmente a cada dia com a existncia de dispositivos cada vez mais acessveis e com a internet mvel sendo implantada em ritmo acelerado se comparado com a ltima dcada. Porm, mesmo que a facilidade de conexo tenha tornado possvel insero de muitas novas pessoas internet, sua capacidade de transferncia evoluiu de forma menos acentuada, juntamente com os dispositivos mveis, que em sua maioria, possuem processamento de dados limitados. As discrepncias nas velocidades de transferncias de dados entre conexes de internet mvel e conexes de banda larga criaram um desao aos pesquisadores, que devem encontrar meios que possibilitem entregar arquivos de mdia a usurios nais com dispositivos que possuem processamentos de dados limitados de forma satisfatria. Ou seja, sem interrupes e com a maior delidade de som e imagem possvel aos usurios que se tornam mais exigente a cada dia. Entre os meios de distribuio de streaming de mdia existentes atualmente, encontra-se o mtodo de streaming adaptativo. Este mtodo aproveita-se da possibilidade de velocidades de conexes diferentes entre seus utilizadores, entregando a eles, de forma diferenciada, os formatos de vdeo que melhor se adapte a ocasio. Desta forma, possvel entregar arquivos com qualidades satisfatrias aos telespectadores, diferenciando-os de acordo com capacidade dos seus dispositivos e velocidades das suas conexes. Este trabalho prope o estudo da tecnologia de streaming, bem como entendimento da sua evoluo durante a massiva disseminao da internet, a m de conhecer seus mtodos alternativos de distribuio, com foco em streaming adaptativo. Ainda, entender algumas das principais ferramentas de distribuio de streaming adaptativos presentes no mercado atual. Como foco deste trabalho, estudar o mtodo de distribuio HTTP Live Streaming, o qual o primeiro mtodo de distribuio de streaming adaptativo a ser proposto como documentao ocial em RFC, com o intuito de tornar-se um padro de distribuio de streaming. Com este estudo, desenvolveu-se um prottipo funcional, capaz de utilizar-se das tcnicas de HTTP Live Streaming para a gerao de streaming adaptativo, sem a necessidade de modicaes em ambientes de distribuio ou recepo de mdia, a m de diminuir custos e facilitar a implementao de ambientes de streaming de mdia. Palavras-chave: HTTP Live Streaming. Streaming Adaptativo. distribuio de vdeo.

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

LISTA DE ILUSTRAES Figura 1 Uma analogia download e streaming com o ato de beber gua . . . . . . . . . . 20 . . 23

Figura 2 Uma representao do funcionamento do HTTP progressive download

Figura 3 Exemplo de uma primeira mensagem de requisio HTTP, por um arquivo de vdeo em um servidor web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Figura 4 Exemplo de uma mensagem de requisio HTTP, por um fragmento de arquivo de vdeo em um servidor web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Figura 5 Uma representao do funcionamento da entrega de HTTP streaming adaptativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 . . . . . . . . . . . . . 36 . . . . . . 41

Figura 6 Exemplo de um cdigo fonte HTML5 com elemento <video>

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

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

Figura 9 Exemplo de um arquivo .M3U8 com variaes de taxa de bits Figura 10 Exemplo grco de arquivos de ndice alternativos

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

Figura 11 Exemplo de um arquivo .M3U8 com ndices alternativos para Proteo Failo ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Figura 12 Fragmento de uma arquivo .htaccess com as linhas de congurao para HTTP Live Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Figura 13 Modelo da sintaxe genrica para FFmpeg Figura 14 Modelo da sintaxe genrica para FFmpeg

Figura 15 Exemplo de um arquivo batch para a fragmentao de vdeo utilizando FFm peg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 . 54

Figura 16 Exemplo de organizao de pastas criadas pelo PHP HLS Fragmenter

Figura 17 Arquivo mestre nal, criado para utilizar os arquivos gerados pelo PHP HLS Fragmenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 37

Quadro 1 Comparao entre TCP and UDP

Quadro 2 Introduo do suporte de vdeo para HTML5 nos principais navegadores web Quadro 3
Suporte de vdeo HTML5 em alguns sites de vdeo de grandes publicaes

(social e comercial)

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

Quadro 4 Atributos de identicao de URI para tag #EXT-X-STREAM-INF Quadro 5 MIME type especco para cada extenso de arquivo

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

Quadro 6 Exemplos de combinaes de fatores para compresso de dados para HLS

Quadro 7 Exemplos de opes de parmetros para converso de vdeo utilizando FFmpeg

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

LISTA DE SIGLAS TCC Trabalho de Concluso de Curso BSI Bacharelado em Sistemas de Informao IST Instituto Superior Tupy EAD Educao a distncia 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

SUMRIO 1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 DISTRIBUIO DE VDEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 16 18 19 20 22 26 27 36 40 49 57 59 62

2.1 MTODOS DE TRANSMISSO DE MDIA

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

2.2 HTTP STREAMING ADAPTATIVO . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 CODECS E CONTINER PARA VDEO STREAMING ADAPTATIVO . . . . . . . . . 3 HTTP LIVE STREAMING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 CODIFICANDO ARQUIVOS DE VDEO COM FFMPEG 4 CONCLUSO

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

REFERNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . APNDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

INTRODUO

evidente que na era digital em que se est atualmente inserido, os mtodos de comunicao mudam constantemente aperfeioando-se conforme o avano tecnolgico dos meios de comunicao. As interaes face-a-face tm sido substitudas de maneira rpida pelos indivduos, que tambm demonstram grande aceitao e muito interesse em mtodos que utilizam a Internet como ponte entre os interlocutores. As formas de comunicao, que minimizam os efeitos da distncia como e-mails ou servios de bate-papo virtual, no mais trabalham sozinhas, mas fazem parte de um ou vrios aplicativos, cuja forma principal a utilizao de contedos em formato de vdeo, como, por exemplo, videoconferncia. Com o intuito de ampliar a discusso, pode-se iniciar o entendimento de como era o funcionamento das entregas de vdeo durante o surgimento massivo da Internet. Para a entrega dos vdeos utilizando a Internet, entre o m da dcada de 1980 e o incio da dcada de 1990, o contedo era gravado e armazenado em computadores remotos, por sua vez, chamados de servidores. Os espectadores, utilizando seus computadores que poderiam estar tanto em suas residncias como tambm em centros educacionais, deveriam acessar esse vdeo por um navegador de Internet utilizando um endereo eletrnico. O vdeo ento entrava no processo de descarregamento, comumente conhecido por download. O download era um processo prtico, porm, em determinados momentos, tornaria-se estressante para o usurio, pois interferncias na conexo poderiam ocasionar oscilaes e corromper o arquivo que estava sendo descarregado. Esta diculdade aumentava ainda mais quando o tamanho fsico do vdeo era demasiadamente grande, o que tambm causava uma longa espera at completar o download. Esse tempo era necessrio, uma vez que para visualizar o vdeo era preciso t-lo por completo na mquina local do usurio. A entrega de vdeo para os espectadores foi revolucionria no mbito de ensino a distncia. Com o crescimento da Internet como meio de educao e com a absoro rpida de vdeo baseado em tecnologias de streaming que, por sua vez, no requeriam o completo descarregamento dos vdeos para poderem ser visualizados. Streaming pode ser denido como a possibilidade de visualizar o contedo do udio ou vdeo, sem a necessidade de t-lo salvo no computador local (KUROSE; ROSS, 2010), alm de ser um mtodo estvel para a disponibilizao de udio e vdeo. Por outro lado, para algumas instituies de ensino, por exemplo, o processo de implantao de tecnologias de distribuio de contedos audiovisuais ainda pode ser considerado demorado e custoso, pois por mais que os equipamentos e tecnologias para a produo de

13

vdeo tiveram decrscimos signicativos de preos nos ltimos anos (ADAO, 2006), h a necessidade de um mnimo de requisitos, entre os quais se destaca a necessidade de um servidor dedicado ao streaming de vdeo. Outro ponto que pode ser analisado que o custo para manter um servidor de streaming de vdeo ainda possui um valor elevado. Alm disso, o streaming de vdeo, em seu conceito principal, tambm chamado de tradicional streaming, utiliza o Procolo de Transporte em Tempo Real - RTP (Real-time Transfert Protocol), onde normalmente so barrados em rewalls, ou ainda encontra diculdades para visualizao ao ser utilizado em dispositivos mveis, como celulares, pois necessitam de aplicaes especcas para se adaptar a este mtodo de distribuio (ISLAM, 2010). Nos anos recentes, pode-se notar uma grande quantidade de provedores de contedo utilizando HTTP Streaming como principal mtodo de distribuio de vdeo. Segundo Islam (2010), isso se deve a quatro fatores: o valor de streaming, baseado no Protocolo de Transferncia de Hipertexto (HTTP), tem custo menor que os servios de distribuio de mdias oferecidos por provedores de hospedagem de vdeo; HTTP Streaming geralmente pode contornar rewalls, pois a maioria dos rewalls permitem o trfego de pacotes HTTP na porta 80, vindo da Internet - enquanto a maioria bloqueia trfego User Datagram Protocol (UDP), que amplamente utilizado nos mtodos padres de streaming; a distribuio utilizando HTTP funciona com qualquer web cache, sem a necessidade especial de alteraes em proxies e caches; o custo para entregar os dados utilizando HTTP muito mais barato que com outros protocolos. A utilizao de HTTP Streaming ganhou imensa popularidade devido s vantagens citadas. Neste trabalho aborda-se o HTTP Streaming Adaptativo, tendo como delimitao a sua anlise de funcionamento e aplicao em um ambiente de ensino. Considera-se a possibilidade de o usurio gerar o contedo, armazen-lo em servidores de distribuio e ser capaz de incorpor-lo a m de disponibiliz-lo aos usurios nais, com facilidade e compatvel com a maioria dos dispositivos conectados a Internet atual. Diante disso, questiona-se: Como desenvolver uma ferramenta de distribuio de contedo audiovisual que utilize mnimos recursos necessrios, requeira mnimas alteraes no sistema operacional e no necessite de alteraes em ambientes de proxies, sem interferir na qualidade audiovisual do contedo recebido pelos espectadores? H de se citar tambm que a quantidade de dispositivos conectados a Internet atualmente vai alm de somente computadores de mesa, chegando at aos dispositivos mveis como celulares com hardwares extremamente pequenos e com processamentos limitados. Estes tambm podem ser utilizados como clientes para entrega de streaming, porm 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 disponveis e as premissas para o desenvolvimento da ferramenta proposta neste projeto, pode-se armar que o estudo das tecnologias para a distribuio de contedos audiovisuais torna-se o principal foco para o sucesso da implementao de uma aplicao para captura, distribuio e recepo audiovisual (THORNHILL; ASENSIO; YOUNG, 2002). Pode-se ainda citar que o tema proposto demonstra-se relevante ao vericar-se a existncia, em fase de desenvolvimento, de uma RFC1 proposta pela empresa Apple, com a nalidade de especicar e documentar a forma de distribuio de vdeos utilizando HTTP Live Streaming (PANTOS, 2011). Vale relembrar que a existncia de ferramentas disponveis, criadas sobre os princpios de cdigo aberto, padronizadas e que possuam facilidade na implementao ainda so escassas, colocam o tema em uma perspectiva oportuna para o momento. O resultado obtido com estes estudos ser importante para o desenvolvimento da ferramenta proposta neste trabalho, e tambm para trabalhos posteriores. Alm de se tornar um estudo em potencial, contribuir para que outras reas importantes como a Educao a Distncia (EAD), por exemplo, possam reduzir custos ou at mesmo a necessidade de implementao de grandes arquiteturas de distribuio de vdeo. Com isso, possibilitar ento enriquecer ainda mais os contedos audiovisuais distribudos aos alunos. O objetivo geral deste trabalho compreender o funcionamento de distribuies de streaming adaptativas, com foco principal no mtodo HTTP Live Streaming como tecnologia de distribuio. Para atingir o objetivo geral, formularam-se os seguintes objetivos especcos: levantar os principais requisitos necessrios para um sistema de captura, distribuio e recepo de vdeo e udio; pesquisar mtodos para compresso de vdeo disponveis para HTTP Live Streaming; desenvolver a aplicao modelo, capaz de utilizar-se da captura de um sinal de vdeo, codic-lo e transmiti-lo utilizando HTTP Live Streaming, bem como receb-lo e reproduzi-lo satisfatoriamente. Buscar-se-, com este desenvolvimento, motivar a utilizao de mtodo de HTTP Live Streaming, demonstrando a facilidade e o baixo custo para sua implementao, alm de motivar o surgimento de novas aplicaes com base nos resultados obtidos. Nesta perspectiva, pelo fato de estar destinada a formular problemas, elucidar as dvidas e construir ideias associadas ao tema escolhido, a metodologia utilizada neste trabalho uma pesquisa de carter exploratrio. Como procedimento, se desenvolveu pesquisa bibliogrRFCs (Request for Comments - pedido de comentrios) so documentos padronizados pela Internet Engineering Task Force (IETF), que tendem a ser detalhados e bastante tcnicos, e descrevem padres de cada protocolo da Internet (KUROSE; ROSS, 2010).
1

15

ca em obras de referncia, manuais, documentos tcnicos e livros introdutrios. A partir da, o desenvolvimento da ferramenta proposta. Este trabalho estrutura-se em quatro captulos. Neste captulo, apresenta-se uma viso geral do trabalho, fato gerador do questionamento da pesquisa realizada, a relevncia do tema, o objetivo geral, os objetivos especcos e a metodologia. Como o foco deste trabalho se destaca o mtodo de streaming, cabe ao segundo captulo uma melhor e mais completa viso e explicao do funcionamento dos mtodos de streaming. Esse mesmo captulo refere-se fundamentao terica, base para esta pesquisa, em que se procura evidenciar os conceitos de streaming, a evoluo das entregas de vdeo utilizando a Internet assim como suas caractersticas. Relata tambm os mtodos de compresso de vdeo de cdigo aberto especcas para HTTP Streaming. O terceiro captulo aborda uma rea especca do mtodo HTTP Live Streaming, o qual a parte fundamental para o desenvolvimento deste projeto, descrevendo suas vantagens, fatores crticos de utilizao e necessidades para implantao. Esse captulo tambm dedicado ao desenvolvimento do aplicativo proposto, desde a escolha do ambiente usado, tenologias e validao da aplicao a ser desenvolvida. E nalmente, o quarto captulo que ser composto da concluso, abordando o desenvolvimento deste trabalho, inferindo a validao dos objetivos propostos, alm das consideraes nais e trabalhos futuros.

16

DISTRIBUIO DE VDEO

Muito foi feito desde o advento e a disseminao das redes de computadores para alm das grandes empresas a respeito das formas e mtodos de distribuio de contedo multimdia, seja para ensino e aprendizado a distncia, seja para teleconferncias, marketing, lazer ou outras aplicaes. O uso de contedo audiovisual vem crescendo exponencialmente a cada dia. Desde a dcada de 1980, que foi marcada por grandes eventos como a proliferao das redes de computadores, surgiram diversas formas de distribuio e armazenamento de contedo audiovisual (KUROSE; ROSS, 2010). J em 1984, a Unio Internacional de Telecomunicaes (ITU) publicou a padronizao do formato de compresso de vdeo H.120, que foi o primeiro padro de codicao de vdeo digital, o qual serviu como base para o estudo de futuros padres de codicao (JACOBS; PROBELL, 2007). Ainda nessa dcada, em 1988, aconteceu o primeiro encontro do grupo de trabalho Moving Picture Experts Group (MPEG), formado pela Organizao Internacional de Padronizao (ISO), e tambm pela Comisso Eletrotcnica Internacional (IEC), visando estabelecer padres internacionais de compresso digital de udio e vdeo (MITCHELL, 2000). Em 1990, com o padro H.261, destinado particularmente a aplicaes que requeriam codicao em tempo real, iniciou-se a prtica de compresso de vdeo digital. Padro este que seria a base para os prximos desenvolvimentos, permanecendo at os dias atuais (MITCHELL, 2000; JACOBS; PROBELL, 2007). Ainda conforme Ghanbari (2003, p. 2), o MPEG iniciou pesquisas para encontrar tcnicas de codicao para armazenamento de vdeos, como CD-ROM. O Objetivo era desenvolver um compressor de vdeo em disco rgido com desempenho comparvel aos gravadores de tas VHF existentes na poca. O primeiro padro desta gerao de compressores foi chamada de MPEG-1, que era capaz de realizar a tarefa de compresso com uma velocidade de at 1.5Mbits/s. Ghanbari (2003, p. 2) cita que com padro MPEG-1 o tempo para a tarefa de compresso e descompresso de um vdeo armazenado, na poca, era ecaz a ponto de no 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 milhes de pessoas no mundo inteiro. A possibilidade de distribuio de contedos diversos, de forma facilitada pela Internet, fez despertar a inovao em diversos desenvolvedores da poca. Em pouco tempo comearam

17

a existir aplicativos grcos, denominadas browsers para a navegao na Internet. A Word Wide Web fez surgir centenas de aplicaes, e dentre elas servios multimdia em tempo real. Neste contexto, Kurose e Ross (2010, p. 44) descrevem ainda que as pesquisas e desenvolvimentos de redes na dcada de 1990 tiveram progressos notveis no desenvolvimento de dispositivos roteadores e roteamento de alta velocidade. Esses avanos impulsionaram ainda mais o desenvolvimento de redes de alta velocidade. Surgiram ainda nessa poca outros formatos de compresso de vdeo, sucessores ao MPEG-1, como MPEG-2/H.262, com suporte a compresses de vdeos com maior resoluo e velocidades de compresso e descompresso ainda maiores, e por consequncia signicativo aumento de qualidade audiovisual. Foi nessa dcada que se iniciou, de forma mais alargada, a distribuio de contedo em tempo real. Em 1995, a empresa pioneira na rea de distribuio de udio e vdeo, a RealNetworks, liberou a primeira verso do produto chamado RealAudio, o primeiro produto at ento distribudo para utilizao de streaming de udio pela Internet. O produto inclua um codicador de udio, um servidor de mdia e tambm um player 1 para executar o udio enviado por este servidor. No ano consecutivo ao seu lanamento, o RealAudio permitiu aos usurios no apenas selecionar e receber udio diretamente, mas tambm distribuir contedos sob demanda, o que rapidamente se tornou popular entre empresas de entretenimento, instituies de ensino e canais de notcias (KUROSE; ROSS, 2010, p. 607). Juntamente com a inovao gerada pela RealNetworks, surgiram tambm novos protocolos de distribuio de mdia em tempo real, como o Real-Time Streaming Protocol (RTSP) (SCHULZRINNE, 1998), um protocolo que estabelece e controla as conexes entre um ou mais uxos contnuo de mdia, como udio ou vdeo. Em decorrncia da massiva aceitao do mercado a esta nova forma de distribuio de contedo audiovisual, outras empresas como Microsoft e Apple iniciaram os seus desenvolvimentos na rea. A partir do incio da dcada de 2000, a penetrao signicativa da Internet nas residncias preparou um ambiente de grandes variedades de novas aplicaes multimdia. Outro aspecto que se pode ressaltar que, nessa mesma dcada, surgiram novos dispositivos de armazenamento de dados de grande capacidade. Eventos esses que inuenciaram diretamente na diversicao das formas de distribuio de streaming. Em 2003, foi proposto o formato denitivo do padro de compresso H.264 (RICHARDSON, 2003), que podia prover servios para aplicaes grcas interativas e multimdia, em especial na Word Wide Web, satisfazendo as
1

Tocadores de arquivos de udio e vdeo

18

necessidades de autores, provedores de servio e usurios nais (LIM; SINGER, 2006) (PANSANATO, 2005). Parte-se do pressuposto que esses avanos tornaram os usurios mais crticos quanto a qualidade audiovisual dos contedos a eles apresentados. Esta exigncia sofreu acentuada importncia com o surgimento de novas tecnologias de acesso Internet, incluindo notria atribuio a dispositivos mveis com acesso a Word Wide Web. Diferentes servidores, players e protocolos foram empregados para mtodos de streaming. Entre os principais, os servios de udio e vdeo de uxo contnuo armazenado tiveram acentuado crescimento entre os usurios da Internet. Esse mtodo foi difundido pela facilidade imposta por servios de compartilhamento utilizando um player de vdeo baseado em ash e incorporado nas pginas web. Entre os precursores e bem sucedidos servios, est o site de compartilhamento Youtube em 2005. Em pouco tempo, o mtodo de uxo contnuo armazenado se tornou uma das principais formas de distribuio de contedo audiovisual na Internet (KUROSE; ROSS, 2010, p. 607). Isso levou vrios estudiosos a se dedicarem a criao de novos mtodos de compresso e distribuio, com o intuito de diminuir o trfego na rede necessrio para enviar o contedo audiovisual ao usurio, e sempre apresentar o contedo com maior qualidade possvel. Com a grande variedade de velocidades de conexo existentes, e em desenvolvimento, para as redes de distribuio, muitos foram os esforos para desenvolver novos mtodos que se adaptassem a essas redes, a m de utilizar o meio de comunicao da melhor forma possvel, sem implicar em constrangimento para o usurio nal ou perdas de qualidade do contedo entregue (ADAO, 2006; BHANDARKAR; CHATTOPADHYAY; GARLAPATI, 2010). Os mtodos de compactao e os formatos que melhor se aplicam ao HTTP Live Stream, sero apresentados posteriormente.

2.1

MTODOS DE TRANSMISSO DE MDIA O mtodo tradicional de transferir um arquivo de um computador remoto a um com-

putador local, utilizando a Internet como meio de comunicao, comumente conhecido pela palavra inglesa download, que pode ter em sua traduo livre para a lngua portuguesa como descarregar. Com este mtodo, a troca de udio e vdeo na Internet baseia-se no esquema download-and-play, em que um player, aps a requisio do arquivo, obrigado a aguardar a completa transferncia do arquivo e t-lo salvo na mquina local para ento poder execut-lo (TABORDA, 2010). Esse mtodo pode ser considerado usual e prtico ao quotidiano quando o produto a ser transferido de dimenso razoavelmente pequena, no entanto, incapaz de satisfazer as necessidades do mercado contemporneo. Para arquivos de grande dimenso, que ocupam

19

grande espao de armazenamento em disco fsico, como um vdeo aula que um professor hospedou em um servidor na Internet, por exemplo, este processo de download se torna um processo custoso, e em determinados momentos com frustraes, por possveis interrupes na conexo com Internet. Visto que as interferncias na conexo podem corromper os arquivos e, por consequncia a necessidade de reiniciar todo o processo, este mtodo considerado inecaz quando se faz necessria a transmisso de mdia de uxo contnuo (ADAO, 2006). Para uma transmisso de mdia de uxo contnuo, usualmente so utilizados softwares especcos ou at mesmo aplicaes especcas instaladas nos servidores de distribuio e um player especco no dispositivo cliente. Com a utilizao deste mtodo, apenas a transferncia de uma pequena poro do arquivo j o suciente para a sua execuo. Esta tcnica de transmisso de uxo contnuo recebe o nome streaming. O cliente visualiza o contedo dos arquivos de udio e vdeo de acordo com a quantidade do arquivo transferido. Por exemplo, no momento em que o usurio requisita o incio do vdeo, ele pode aguardar alguns segundos at a transferncia de uma pequena poro, equivalente a alguns segundos do vdeo para preencher o buffer do player, isso ser o suciente para iniciar a execuo e o usurio iniciar a visualizao o contedo do vdeo.

2.1.1

Streaming

Pela relevncia empregada frequentemente ao decorrer deste trabalho, foi considerada pertinente a denio de streaming nesta seo, visando a compreenso mais aprofundada do tema, sintetizando os conceitos bsicos e essenciais desta tecnologia. De acordo com Adobe (2001), a tecnologia streaming permite, em tempo real ou sob demanda, acesso a udio, vdeo ou contedo multimdia atravs da Internet ou em uma intranet. A mdia, em formato streaming, transmitida por um servidor de mdia especializado ou por uma aplicao especca, e processada e reproduzida ao usurio por um player especco, tal como recebida, sem deixar cpias residentes no dispositivo receptor. Ainda pode-se acrescentar que, para a reproduo do contedo recebido no player, basta uma pequena espera de tempo inicial para a sincronizao e a criao de uma memria temporria, denominada buffer, para armazenar alguns segundos do contedo. Esta memria temporria utilizada para absorver possveis interrupes na conexo que interferem diretamente no ritmo de recebimento do contedo, causando pausas na execuo, que podem acarretar em decepes ao usurio que est visualizando o contedo (ADAO, 2006). Para exemplicar de forma natural, Kozamernik (2002) faz uma analogia entre a transmisso streaming e o ato de beber gua de um copo. A gura 1 exemplica a analogia, em que o autor descreve que o download comum como voc utilizar uma garrafa para encher um

20

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

Figura 1: Uma analogia download e streaming com o ato de beber gua

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

Segundo Islam (2010), o streaming est baseado em trs mtodos gerais: streaming tradicional, download progressivo e HTTP streaming. As subsees a seguir descrevem essas trs tcnicas de streaming.

2.1.2

Streaming Tradicional

Este mtodo tambm chamado de True Streaming, ou Streaming Real, requer uma arquitetura diferente da usada para download, normalmente utilizando servidores dedicados de distribuio. Ele suporta uma interatividade muito maior com o usurio, garantindo tambm um grande nmero de vantagens adicionais. Em uma distribuio de contedo utilizando streaming tradicional, quando este no for em tempo real2 , possvel permitir que o espectador possa saltar o tempo de execuo do contedo audiovisual tanto frente quanto para trs. Protocolos especcos so utilizados para o transporte de dados entre o servidor e o cliente, gerando a necessidade de aplicativos especcos para a troca de dados entre eles. Um dos protocolos tradicionais streaming o Real-time Transport Protocol (RTP) (SCHULZRINNE et al., 2003).
Quando citamos as palavras em tempo real sobre o assunto de distribuio de vdeo, signica que o cliente recebe um uxo contnuo com um valor mnimo de atraso, onde a transmisso e recepo do contedo quase instantnea (KOZAMERNIK, 2002).
2

21

O RTP opera utilizando protocolo UDP para o envio dos pacotes de dados. Esta escolha torna o protocolo de transporte simples e eciente, porm deixa a desejar no mbito de garantir a entrega dos dados ao cliente. Para ns de entendimento sero comparados os protocolos de transporte UDP e Transmission Control Protocol (TCP), melhor abordado no quadro 1: Quadro 1: Comparao entre TCP and UDP TCP Orientado a conexo - uma conexo criada antes da transferncia de dados. Convel. Dois canais de comunicao, aumentando a interatividade entre o cliente e o servidor. Correo de erros. Controle de uxo. Gerencia a taxa de download. Reenvia pacotes perdidos. No predetermina taxa de entrega. O TCP ir aumentar a taxa de dados at que haja perda de pacotes que indique congestionamento. UDP No orientado a conexo - no h necessidade de estabelecer uma conexo. No convel. Unidirecional, sem interatividade, apenas iniciar e parar. Somente detecta os erros, faz uma vericao dos dados - checksum. No possui controle de uxo. No reenvia pacotes perdidos. A taxa de entrega deve coincidir com a taxa de uxo codicado. Diferentes codicaes para um mesmo contedo pode ser necessrio para ajustar diferentes canais de entrega com taxa de entrega varivel. Sem cache local - os pacotes so processados pelo player multimdia conforme so recebidos

Tolerncia de buffer overow: se os dados chegarem rpido demais, o receptor envia mensagem para o servidor para desacelerar o envio

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

Apenas com a misso de transportar os dados entre o cliente e o servidor, o protocolo RTP necessita de um controle de sesso do cliente, e tambm de um canal para o cliente enviar comandos ao servidor, como, por exemplo, a ao de pausar, parar ou continuar a reproduo. Para sanar esta necessidade, foi criado o protocolo de controle Real-Time Transport Control Protocol - RTCP (SCHULZRINNE et al., 2003). Atualmente o protocolo padro para emisso de comandos de controle o RTSP. De acordo com Schulzrinne (1998, p. 4):
O RTSP estabelece e regula um nico ou vrios uxos sincronizados de mdias contnuas ao mesmo tempo. Ele no costuma entregar os uxos contnuos em si, embora a intercalao do uxo de mdia contnua com o uxo de controle seja possvel. Em outras palavras, RTSP age como um controle remoto para servidores multimdia.

22

Agindo como controle remoto, existe a possibilidade do cliente requisitar alteraes no contedo enviado pelo servidor. Se a velocidade de conexo entre o cliente e o servidor diminuir durante a reproduo, uma das alteraes que pode ser realizada alternar entre as qualidades disponveis do vdeo que est sendo enviado pelo servidor, com o objetivo de no gerar pausas na reproduo do contedo. Apesar de no fazer parte do foco deste trabalho, se faz interessante citar que o uso do streaming tradicional proporciona um grau de segurana maior sobre outros mtodos de distribuio, quando o contedo em transmisso contm direitos autorais. Isso se d por que neste mtodo, usando UDP como protocolo de transporte, o contedo enviado ao player do receptor no armazenado no cliente e nem permanece como arquivo temporrio no disco rgido do dispositivo receptor. O player simplesmente recebe o contedo, o decodica e o exibe ao mesmo tempo que descarta logo aps a sua exibio (KOZAMERNIK, 2002; LARSON; COSTANTINI, 2007). Por outro lado, uma grande maioria dos rewalls bloqueia todos os trfegos UPD, e tambm pelas circunstncias positivas que aparentam ser maiores, visto no quadro 1, faz com que cada vez mais se utilize aplicaes que atuem sobre TCP (PFEIFFER, 2010). Nesta perspectiva, existe um mtodo de distribuio que comumente utilizado e teve um aumento expressivo de uso com a facilidade de implementao, pois no requer grandes modicaes ou complexos sistemas de distribuio. Este mtodo conhecido como HTTP progressive download.

2.1.3

HTTP Progressive Download

Recapitulando o entendimento do mtodo de download, descrito no incio desta seo, em que cita a facilidade de distribuio de arquivos de vdeo por intermdio de descarregamento, o mtodo HTTP progressive download para udio e vdeo na web um dos mtodos 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 conexo com o servidor tratada como uma conexo nova, cabe a aplicao manter o controle da conexo. Alm disso, o HTTP roda sobre protocolo TCP, que como visto no quadro 1, uma das principais diferenas entre o UDP e o TCP. Esse ltimo utiliza vrias tcnicas para proporcionar conabilidade na entrega dos dados (KUROSE; ROSS, 2010). Daras e Ibarra (2009) relembram ainda que este mtodo consiste na utilizao de um arquivo de mdia previamente gravado e armazenado em um servidor Web, porm diferencial-

23

mente do mtodo de download comum, com o HTTP progressive download, o cliente comea a reproduzir o contedo de mdia antes mesmo do download completo do arquivo. Para uma melhor utilizao deste mtodo, comumente utilizado um player especco para a recepo e a execuo do contedo audiovisual. A medida que este player recebe o arquivos que est sendo descarregado do servidor, ele armazena estes dados em uma memria temporria do player denominada buffer. Esta memria utilizada exclusivamente para absorver alteraes do ritmo de recepo dos dados, ou at mesmo para inibir pausas causadas por falhas na conexo. Tambm diferente do mtodo streaming tradicional, no HTTP progressive download, o arquivo que requisitado ao servidor recebido em fragmentos do arquivo completo. Nesta situao, 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 fsico do cliente, normalmente na pasta de cache do browser. Uma representao do processo descrita na gura 2.

Figura 2: Uma representao do funcionamento do HTTP progressive download

Fonte: adaptado de Daras e Ibarra (2009, p. 221)

Utilizando este mtodo, possvel saltar de uma posio de tempo de execuo do udio ou vdeo, para outra que foi previamente carregada no buffer do player. Como descrito anteriormente, este mtodo proporciona o salto de tempo somente quando o player possui um buffer e a posio de salto estiver previamente completa no buffer. Novos mtodos foram desenvolvidos a partir do funcionamento do HTTP progressive download, a ponto de melhorar a experincia com o usurio.

24

Para sanar a necessidade de permitir que o utilizador possa saltar o tempo de execuo para uma posio que no foi previamente descarregada, foi criada uma derivao do HTTP progressive download nomeado de Seek streaming, tambm chamado de Pseudo streaming (TABORDA, 2010). O cabealho de mensagem, do protocolo HTTP em sua verso 1.1, possui um campo chamado Accept-Ranges que torna possvel a utilizao do Seek Streaming (BERNERS-LEE et al., 1999). Quando a aplicao faz a primeira requisio do contedo por intermdio de uma Uniform Resource Identier - URI, caso a resposta do servidor seja positiva, normalmente envia no cabealho da mensagem de resposta o tamanho em bytes do arquivo requisitado. A aplicao, sabendo o tempo e o tamanho do arquivo atravs dos cabealhos de resposta HTTP, normalmente exibe para o utilizador uma barra demonstrando o buffer de carregamento do contedo em forma temporal. Quando o utilizador salta para uma determinada posio de tempo do player, a aplicao faz a requisio passando como valor ao parmetro Ranges no cabealho HTTP, os bytes referente a posio temporal do arquivo. Este valor deve obrigatoriamente ser um nmero real inteiro que compreenda entre zero e o total de bytes do arquivo.

1 2 3 4 5

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

Figura 3: Exemplo de uma primeira mensagem de requisio HTTP, por um arquivo de vdeo em um servidor web

1 2 3 4 5

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

Figura 4: Exemplo de uma mensagem de requisio HTTP, por um fragmento de arquivo de vdeo em um servidor web Pode-se notar que, na gura 3, o campo Range possui como primeiro valor byte o valor zero, no informando o segundo valor. Estes dois valores separados por um hfen so enviados ao servidor como parmetro de intervalo esperado como retorno. Ao contrrio da gura 3, na gura 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 nal esperado. Caso o segundo valor esteja ausente ou tenha um valor maior que o tamanho total do arquivo, considerado que o valor nal seja o ltimo valor de byte do arquivo (BERNERS-LEE et al., 1999). Assim, facilmente vericvel que, graas a este aspecto, torna-se possvel pausar o descarregamento na sua aplicao e recomear o descarregamento de arquivos por uma conexo HTTP. Aponta-se agora outra peculiaridade que, pela utilizao do protocolo HTTP, qualquer servidor web (como, por exemplo, Apache ou Intenet Information Service - IIS) pode ser utilizado como servidor de distribuio dos arquivos de udio e vdeo sem grandes necessidades ou mudanas na infraestrutura (ISLAM, 2010). Pode-se ainda, encontrar a citao de HTTP Fake streaming referenciando a utilizao de scripts no lado servidor para a utilizao de streaming, e este recebendo o nome de HTTP streaming. Antes de prosseguir com a apresentao deste mtodo, necessrio explanar melhor este funcionamento de distribuio que se assemelha em vrios aspectos com o HTTP streaming, porm nativamente utiliza HTTP Progressive Download por meio de Pseudo streaming. Esses scripts, ao receberem uma requisio para descarregamento de um arquivo, iniciam um processo de leitura de um arquivo que est armazenado sicamente no servidor, e sequencialmente envia partes deste arquivo completo para a aplicao que o requisitou. Enquanto o HTTP Progressive Download permite saltar um perodo temporal de um contedo previamente carregado no buffer de um player, no HTTP Fake Stream, o player que est sendo utilizado pelo cliente permite ao usurio realizar a tentativa de salto para um perodo temporal do contedo que ainda no foi previamento carregado no buffer. Essa peculiaridade s possvel na utilizao de arquivos de vdeo que foram codicados utilizando keyframes inseridos no arquivo o qual enviado aplicao cliente que far a reproduo do vdeo. Os keyframes, presentes em formato de texto na sesso de metadados do cabealho HTTP, so necessrios para que o player possa congurar a timeline do vdeo. Estes metadados normalmente no ultrapassam mais do que vrios kilobytes (PFEIFFER, 2010). Pfeiffer (2010) relembra que metadados um termo utilizado em vrios e diferentes contextos com vdeo, por isso necessrio compreender o contexto para entender o que exatamente est sendo referido pelo atributo. A partir deste momento, o aplicativo envia uma requisio para o servidor, que recebido pelo script que est servindo o contedo. Esta nova requisio contm, junto ao nome do arquivo requisitado, um valor, informando ao script a partir de qual posio do arquivo ele deve iniciar a leitura e ento responder ao aplicativo que o requisitou.

26

Tiwari e Elrom (2010) descrevem em seu livro a utilizao da linguagem de programao server-side Hypertext Processor (PHP), chamando essa utilizao de PHP streaming. Logicamente este nome se deve pelo fato da utilizao 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 programao server-side, capazes de realizar manipulaes de arquivos localmente, antecedendo o nome streaming, dando referncia ao script utilizado. Porm ainda assim, o mtodo utilizado para entrega do contedo o HTTP Streaming. Pode-se citar um problema quanto a utilizao de HTTP progressive download: a menos que o uxo de mdia seja encerrado, todo o arquivo ser baixado para o cliente. Islam (2010) relembra que aps o player ter requisitado a mdia utilizando o HTTP progressive download, mesmo que o usurio interompa o player de mdia, o arquivo continua sendo enviado pelo servidor at seu timeout, utilizando os recursos de transferncia de dados do servidor.

2.1.4

HTTP streaming

Como descrito nas sesses anteriores, poucas ou quase nenhuma modicao necessria no servidor web para servir streaming por HTTP. O benefcio de estar onipresente na Internet, juntamente com o baixo custo e a facilidade para implementao, sem necessidade de modicaes no ambiente do servidor web, tornou-se rapidamente o mtodo popular de distribuio de contedos audiovisuais. Consecutivamente, fornecedores de contedo aceitaram e vem difundindo amplamente a utilizao de HTTP progressive download enquanto desenvolvem seus prprios mtodos e caractersticas para melhorar o streaming por HTTP (PFEIFFER, 2010). importante ressaltar que, neste trabalho, a armao no haver necessidade de realizar modicaes no servidor web, deseja-se tornar claro que servidores de hospedagem normalmente disponveis na Internet possuem um padro de conguraes e aplicaes instaladas em seu sistema operacional, e esses em sua grande maioria no possibilita alterar conguraes ou realizar instalaes de outros aplicativos. De modo geral, qualquer extenso de software aplicativo utilizado para possibilitar o streaming de mdia no pode ser instalado em servidores de hospedagem que no permitam tais modicaes. Esclarecido esse aspecto, volta-se outra vez questo do mtodo de distribuio de streaming sobre conexes HTTP. Pfeiffer (2010) cita que uma caracterstica em particular que tem feito com que os fornecedores criem novas tecnologias, mtodos de distribuio para aproveitar ao mximo as caractersticas positivas de transmisso de contedo utilizando protocolo HTTP. Dentre a mais notria est a transmisso adaptvel por HTTP.

27

O HTTP streaming adaptativo, descrito de forma sucinta por Pfeiffer (2010), consiste na entrega do vdeo ao usurio dependendo exclusivamente das condies da rede e do software do usurio, tal como o ambiente atual, a m de garantir a melhor experincia possvel para o telespectador.

2.2

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

o contedo de entrada, ou seja, o arquivo de vdeo a ser enviado pelo servidor. O arquivo de entrada dividido em uma srie de pequenos arquivos, os quais, no presente trabalho adotase a nomenclatura fragmentos para represent-los. Cada um destes fragmentos pode ser codicado 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 tcnica de download progressivo. De acordo com Islam (2010), a denio de adaptao baseada pelo ato do player cliente escolher uma verso com formato especco de cada fragmento. A verso do fragmento solicitado pelo cliente baseada em uma estimativa das condies atuais da rede e da carga sobre o servidor. Em situaes em que a rede ou o servidor estiver sobrecarregado, por exemplo, o cliente ento solicita uma verso com caractersticas pequenas, normalmente com uma qualidade audiovisual mais baixa. Caso contrrio o cliente solicita uma verso de maior qualidade, ou seja, proporcionando uma maior resoluo e maior delidade de cores. A gura 5 demonstra a entrega dos fragmentos de mdia requisitados pelo cliente.

Figura 5: Uma representao do funcionamento da entrega de HTTP streaming adaptativo

Fonte: adaptado de Zambelli (2009, p. 8)

28

Pfeiffer (2010) descreve que recentemente o grupo MPEG vem trabalhando na padronizao de uma especicao para HTTP streaming adaptativo, o qual eles nomearam de Dynamic Adaptive Streaming for HTTP (DASH) na publicao do primeiro draft deste padro de desenvolvimento durante sua reunio 933 na cidade de Geneva no estado de Switzerland. DASH especica os formatos que permitem a entrega de mdia atravs de servidores HTTP padres para clientes HTTP. O grupo MPEG prev alcanar o status nal para publicao, aproximadamente, em novembro de 2011. No entanto, Pfeiffer (2010) tambm arma que existe, em paralelo ao DASH, projetos sendo discutidos para uso de CODECs de cdigo aberto em geral, pelo Web Hypertext Application Technology Working Group (WHATWG)4 , que formado por pessoas com interesses em comum voltados a evoluo do HTML e de tecnologias ligadas a tal. Arma ainda que h uma expectativa que no ano de 2012, seja criado uma soluo genrica e de cdigo aberto para a utilizao de HTTP streaming adaptativo. Por enquanto, como no existe uma padronizao para a utilizao desta tecnologia, vrios fornecedores ao ver a potencialidade da utilizao desta tecnologia, esto criando suas prprias extenses para melhorar a forma de distribuio de vdeo sobre HTTP. Dentre as solues de fornecedores que esto disponveis no mercado e que se destacam no avano ao utilizarem HTTP streaming adaptativo, se fazem notrios trs: Microsoft Smooth Streaming, Adobe HTTP Dynamic Streaming e Apple HTTP Live Streaming (PFEIFFER, 2010). Cada uma destas novas extenses possui caractersticas que as diferem das demais, assim como a utilizao de CODECs padres para compresso de udio e vdeo. Em algumas, h a separao de canais de udio e vdeo em uma comunicao streaming, em outras o funcionamento da adaptao servida aos player de contedo. As trs solues citadas acima, que se destacam entre as existentes, sero descritas a seguir com o intuito de diferenci-las.

2.2.0.1

Microsoft Smooth Streaming O Microsoft Smooth Streaming foi desenvolvido utilizando a caracterstica de transportar

streaming sob conexes HTTP. Ele necessita que o servidor de distribuio seja um IIS com pacote de extenso IIS Media Services instalado, alm do aplicativo Expression Encoder para a codicao do vdeo para a sua utilizao (MACDONALD, 2009; GHOSH; CAMERON, 2010). Com esta tecnologia, possvel a distribuio de vdeo sob demanda e tambm ao vivo. Para o recebimento e execuo da mdia no cliente, necessrio possuir o plugin Microsoft Silverlight instalado no browser cliente para a exibio do player compatvel com tal tecnologia.
As reunies do grupo MPEG so numeradas em ordem crescente a cada novo evento que rene o grupo Mais detalhes esto acessveis no endereo eletrnico mantido pelo grupo: http://wiki.whatwg.org/wiki/Adaptive-Streaming
4 3

29

Para a criao do streaming adaptativo, o Smooth Streaming codica, utilizando o aplicativo Expression Encoder, o contedo de uma mesma fonte que normalmente um arquivo de vdeo de alta denio, em vrios nveis de qualidade diferente, porm tambm completos. O contedo ento entregue atravs do servidor IIS com Smooth Streaming habilitado. O player cliente, ao requisitar a mdia ao servidor IIS, o Smooth Streaming cria fragmentos virtuais dinamicamente a partir de um dos arquivos codicados anteriormente, e os envia sequencialmente ao player cliente. Estes fragmentos virtuais normalmente so separados em espaos de 2 segundos de contedo (GHOSH; CAMERON, 2010; MICROSOFT, 2011). O funcionamento do Smooth Streaming baseado em algumas etapas. Primeiramente um arquivo de vdeo modelo, de alta qualidade, utilizado para gerar outras cpias deste vdeo com maiores compactaes. Cada um dos arquivos gerados pelo Expression Encoder possui uma extenso .ismv e cada um deles contm o vdeo original codicado em taxas de bits especcos. Por exemplo, um vdeo, quando codicado a uma taxa de 128bits utilizando o Expression Encoder, gera um arquivo com o nal 128.ismv, e assim sucessivamente para cada taxa de codicao, a m de organizar e manipular os arquivos nais. Para cada uma das taxas convertidas, o arquivo nal .ismv contm 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). Alm dos arquivos de vdeo em codicaes diferentes, tambm pode ser gerado um ou mais arquivos com a exteno .isma. Esse arquivo, codicado semelhantemente ao .ismv, contm o udio referente ao vdeo em questo, ou ainda pode existir somente os arquivos .isma caso o contedo a ser utilizado seja somente udio. Estes arquivos de vdeo para a utilizao do streaming utilizando Smooth Streaming so codicados utilizando MPEG-4 Part 14, tambm conhecido por MP4 (TABORDA, 2010). Juntamente com estes arquivos, gerado um arquivo .ism, chamado de arquivo manifest do servidor e em seu contedo armazenado o mapeamento de cada arquivo ISMV e ISMA, seus nveis de qualidade e taxas de bits. Este arquivo utilizado pelo servidor para acessar o fragmento especco no arquivo em disco quando requisitado pelo cliente. Neste arquivo ISM tambm contm armazenado o caminho de um arquivo manifest utilizado pelo player cliente, o qual recebe a exteno .ismc. Este arquivo possui todas as informaes necessrias para que o player cliente possa reproduzir o contedo de forma adequada, como por exemplo informaes sobre os nveis de qualidade disponveis, informaes de tempo de cada fragmento, metadados, entre outras informaes. Logo aps o player cliente receber o arquivo manifest ISMC, ele faz a leitura e inicia as requisies de cada fragmento da mdia, 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 utilizao necessrio um servidor com sistema operacional Windows, e para distribuio de vdeos ao vivo, requisita especicamente do Expression Encoder e ambos requerem a compra de licenas especcas (GHOSH; CAMERON, 2010, p. 949-951). No entanto, existem mdulos capazes de possibilitar a outros aplicativos que utilizam distribuio HTTP, como Apache5 , a servidor HTTP Smooth Streaming. Como o pr-requisito para este trabalho a utilizao de tecnologias e ferramentas que proporcionem o desenvolvimento de um produto com conceito de cdigo aberto e baixo custo para implantao, optou-se por descartar o Microsoft IIS Smooth Streaming pelo necessidade de possuir licenas especcas para utiliz-la em seu ambiente, ou em outros casos a necessidade de instalao de mdulos no triviais para complementar o servidor web a m 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 tambm

uma adaptao, desenvolvida pela empresa Adobe, para transportar streaming sob conexes 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 distribuio de contedo, o formato F4V, gerando arquivos com a extenso .f4f (ADOBE, 2010). Segundo Adobe (2010), os fragmentos F4F, e tambm MP4 que extendido do MPEG-4 Part 12, so utilizados tanto para streaming ao vivo e sob demanda com suporte total para a CODECs de alta qualidade de mdia disponveis na Plataforma Adobe Flash. Pode-se armar ento que, para a utilizao do HTTP Dynamic Streaming como tecnologia de streaming, necessrio que o player cliente seja desenvolvido em plataforma Adobe Flash, comumente chamada de Flash Player. Esta restrio torna-se um empasse quando se analisa a atual era tecnolgica, percebendo que nem todos os dispositivos capazes de serem utilizados para streaming de vdeo suportam ou possibilitam a instalao de Flash Player. Um exemplo desta armao o dispositivo tablet iPad da empresa Apple (SAMPAIO, 2011, p. 38). O HTTP Dynamic Streaming utiliza exclusivamente MP4 ou VP6 como CODECs de compresso de dados em alta qualidade e que tambm so compatveis com a plataforma Adobe Flash. E assim como o Microsoft Smooth Streaming, tambm possui um aplicativo que realiza a codicao dos vdeos originais, o preparando para o distribuir posteriormente. Adobe
5

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

31

desenvolveu um aplicativo para a preparao dos vdeos previamente gravados e para a distribuio 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 distribuio de contedo, pode ser utilizado usando o software de servidor web Apache padro e infraestruturas de cache. A m de facilitar a implantao, a Adobe disponibiliza um mdulo6 adicional ao Apache que pode ser instalado no servidor para ser usado na distribuio do HTTP Dynamic Streaming (ADOBE, 2011). O aplicativo codicador para vdeo previamente gravado disponibilizado gratuitamente pela empresa desenvolvedora, e apenas o aplicativo codicador para a verso de distribuio em tempo real requer uma licena que vendida separadamente pela empresa distribuidora. Durante a preparao do arquivo de vdeo para a preparao no formato de distribuio sob demanda, quando utilizado o HTTP Dynamic Streaming, so gerados dois arquivos. Um arquivo possui a extenso F4F que possui todos os fragmentos MP4 compilados. Um segundo arquivo recebe a extenso F4M, e nele existem textos baseados em um arquivo Extensible Markup Language(XML) formando o arquivo manifest, contendo informaes de inicializao, informaes de taxa de bits, metadados de informaes de licena do servidor utilizado, entre outras informaes (ADOBE, 2010). Como essa seo aborda tecnologias de streaming adaptativos, assim como o Microsoft Smooth Streaming, o HTTP Dynamic Streaming tambm pode utilizar mais arquivos de vdeo codicados com taxas de bits diferentes para a adaptao. No entanto, como relembra Adobe (2010), algumas consideraes devem ser feitas para garantir uma reproduo adequada para o telespectador. O autor enuncia que uma das consideraes importantes a perfeita sincronizao dos keyframes tambm chamados de quadros-chave, que so utilizados como um guia a m de determinar o incio e o m dos fragmentos do arquivo. Isto porque como o Microsoft Smooth Streaming, ao utilizar o HTTP Dynamic Streaming, o servidor de mdia cria fragmentos virtuais de acordo com os keyframes. Como o Flash Player muda o tempo de reproduo do player de acordo com os keyframes, caso todos os keyframes entre os arquivos codicados com taxas de bits diferentes estejam alinhados, a troca do arquivo na adaptao de taxa de bits torna-se imperceptvel ao telespectador (ADOBE, 2010). Para a distribuio em tempo real, s ferramentas disponveis funcionam semelhantemente ao modo de distribuio sob demanda. A Adobe disponibiliza uma ferramenta chamada de Live Packager que converte as entradas ao vivo em formato de transmisso Real-Time Messaging Protocol (RTMP), que um protocolo proprietrio da Adobe, o qual muito parecido com o RTSP (PFEIFFER, 2010). Para tal, utilizado como servidor de distribuio compatvel
6

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

32

chamado de Flash Media Server que tambm um software proprietrio da Adobe. Porm ainda existem ferramentas open source como, por exemplo, o Red5. Todavia, para a utilizao do Red5 necessrio 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 necessrio esta tecnologia proprietria, a Adobe aproveitou para criar mdulos especcos dentro da sua tecnologia Flash a favor de aumentar signicativamente a interao avanada entre o player cliente e o servidor de distribuio de mdia. Para possibilitar a disseminao do uso de sua tecnologia, a Adobe desenvolveu um framework gratuito de cdigo aberto, desenlvolvido utilizando ActionScript 3.0 o qual recebeu o nome de Open Source Media Framework 7 (OSMF). Este framework possibilita aos desenvolvedores criarem player de mdia personalizados, capaz de integrar outras extenses desenvolvidas por terceiros, e com total suporte a HTTP Dynamic Streaming. Um player desenvolvido utilizando OSMF suporta tanto o streaming por HTTP como tambm streaming por RTMP (ADOBE, 2010). Com a utilizao do OSMF Player, possvel monitorar o ambiente onde o dispositivo cliente est inserido e, de acordo com as alteraes nesse ambiente, escolher qual taxa de bits deve requisitar ao servidor de mdia, para que possa proporcionar a melhor experincia possvel ao usurio. Apesar da possibilidade de ser implantando utilizando as ferramentas gratuitas disponveis, o HTTP Dynamic Streaming requer modicaes no sistema operacional do servidor, de modo que estas modicaes no sejam triviais para as conguraes de um servidor web. Alm disso, h necessidade de utilizao de Flash Player como plugin proprietrio para a utilizao desta soluo, o que cria um ponto negativo em sua anlise de implementao, relembrando ainda que existem dispositivos que no possuem possibilidade de instalao deste plugin em seu sistema operacional. Observa-se nitidamente que a utilizao desta soluo de streaming adaptativo no 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 trs extenses citadas a mais jovem e com possibilidades de ser aceito como um padro ao se analisar suas propriedades e o ambiente em que est sendo desenvol7 Mais detalhes sobre Open Source Media Framework esto disponveis no endereo eletrnico: http://opensourcemediaframework.com/

33

vida. A abordagem dele amplamente especicada em um draft8 para RFC, tendo uma boa evoluo desde sua primeira verso em maio de 2009 at a stima publicao em setembro de 2011 (atual verso a qual foi utilizada para captao e explorao das informaes sobre o tema). Dentre as trs extenses do HTTP Streaming adaptativo citadas at ento, esta a nica que possui sua proposta aberta em uma publicao, descrevendo todo o seu funcionamento, acessvel a qualquer indivduo. Desde a primeira verso do draft, que descrevia a verso 1 desta extenso, em que o draft o descreve como um protocolo para transmisso de streaming ilimitado de mdia sobre HTTP, vrias melhorias foram implementadas, mas seu conceito ainda permanece o mesmo: especicar o formato dos dados dos arquivos e as aes que o servidor deve tomar e como o player cliente deve agir. A verso mais atual cita que a verso utilizada do protocolo a verso 4 (PANTOS, 2011). O HLS parecido com o funcionamento das outras extenses anteriormente citadas, porm possui aspectos e propriedades especcas encontradas somente nele. Pode-se citar a forma de armazenamento dos fragmentos de mdia, a forma de distribuio, o mtodo de execuo e a tecnologia utilizada para o desenvolvimento do Player cliente. Ao contrrio do HTTP Dynamic Streaming e Microsoft Smooth Streaming, que criam fragmentos virtuais que esto salvos em um nico arquivo convertido em uma taxa de bits especcos, o HTTP Streaming utiliza fragmentos fsicos, separados e armazenados no servidor de distribuio (PANTOS, 2011). Estes fragmentos so gerados a partir do componente servidor, utilizando como entrada o vdeo original, e recebendo os parmetros especcos para congurao e gerao dos fragmentos ao mesmo tempo em que altera a taxa de bits, tambm especicada nos parmetros. Para ns 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 uxo de entrada ou um arquivo fsico previamente gravado, codic-lo e dividi-lo em uma srie de pequenos arquivos de mdia de igual durao de tempo. Estes pequenos pedaos normalmente so encapsulados com uxo de transporte MPEG-2. Este formato suporta uma grande variedade de formatos de compresso de udio e vdeo (APPLE, 2011). Os fragmentos gerados normalmente so fragmentos iguais de 10 segundos, os quais recebem como extenso .ts, abreviao de MPEG transport stream que especicado no MPEG-2. Nas outras extenses de HTTP adaptativo citadas anteriormente, era gerado um arquivo chamado de manifest o qual possua informaes sobre os arquivos disponveis para a adaptao bem como informaes necessrias para a utilizao do mtodo adaptativo. No HTTP
8 Um rascunho, pode ser uma apresentao individual ou uma apresentao do grupo de trabalho. Quando um rascunho considerado maduro por um grupo de trabalho se torna uma RFC (ZAPATA, 2006)

34

Live Streaming, apesar de utilizar uma forma diferente de armazenamento, tambm possui um arquivo manifest que gerado a partir do Segmentador de HLS e comumente chamado de arquivo de ndice. Este arquivo contm referncias dos arquivos, segmentos de mdia, gerados e salvo em formato de lista de reproduo (playlist) M3U8 (PANTOS, 2011). O arquivo M3U8 consiste em um arquivo de texto simples, contendo nele um ou diversos endereos dos arquivos fragmentados sequencialmente, endereo este que recebe o nome de Uniform Resource Locator (URL), alm de tags especcas, utilizadas como parmetros e informaes pelo player cliente. O Segmentador de HLS no necessariamente deve estar no mesmo servidor de distribuio. Ele pode estar em qualquer hospedeiro que possua suporte para realizar as atividades. A Apple disponibiliza vrias ferramentas para gerar os arquivos necessrios para HTTP Live Streaming. O streaming ao vivo e sob demanda no HTTP Live Streaming trabalham de forma parecida. O mtodo de streaming ao vivo utilizando o HTTP Live Streaming possui caractersticas particulares e bem diferentes do mesmo mtodo em seus concorrentes. Como descrito no pargrafo anterior, no necessrio que o segmentador de HLS esteja no mesmo hospedeiro que o servidor de distribuio, este ltimo pode ser qualquer servidor web que sirva os arquivos requisitados sobre conexes HTTP. Isso porque o projeto do HLS, assim como a proposta deste trabalho, requerer mnimas mudanas na infraestrutura do servidor de distribuio. So vrios os softwares que podem ser utilizados como servidores web cache para distribuio de HTTP Live streaming. Entre eles pode-se encontrar Microsoft IIS para servidores Windows, e tambm Apache para servidores Linux. Atualmente a verso estvel do Apache j inclui como padro em seu arquivo de congurao9 de MIME types a especicao para arquivos .M3U8. Ento, infere-se que pelo fato do papel do servidor de distribuio ser apenas aceitar as requisies e respond-las, nenhuma modicao nele necessria para a utilizao do HTTP Live Streaming. Isso um ponto positivo ao comparar com o propsito deste trabalho. H de se citar, tambm, que diferente das outras extenses citadas anteriormente neste captulo, o player utilizado para o HTTP Live Streaming no utiliza nenhum framework ou plugin proprietrio para a execuo do contedo audiovisual. Nesse sentido, faz-se apropriada a denio de que, pelo fato de como o protocolo est sendo desenvolvido e o seu funcionamento aberto ao pblico devido ao acesso do draft da RFC, diversos players podem ser desenvolvidos utilizando qualquer tecnologia que possua linguagem de programao disponvel, e que essa seja capaz interagir com requisies HTTP e incorporar reproduo de vdeo em seu contedo.
9 Arquivo que faz parte do pacote de instalao do Apache verso 2.3.15. Visualizao disponvel na URL: http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types

35

Apple (2011) arma que o HLS est em funcionamento para os dispositivos que possuem o sistema operacional iOS10 verso 3.0 ou maior e em computadores com sistema operacional Mac OS X ou superior. O autor descreve ainda que o navegador web Safari possui, nativamente em seu cdigo, a interpretao de HTTP Live Streaming utilizando tag <video> que faz parte nativamente do HyperText Markup Language (HTML), na verso mais atual em desenvolvimento - o HTML5 (PFEIFFER, 2010). O HTML5, j presente nos navegadores mais atuais, uma atualizao da atual verso HTML suportada pela maioria dos navegadores e, possui novos recursos que anteriormente eram possveis somente por meio de outras tecnologias incorporadas. Pfeiffer (2010) cita ainda que, no desenvolvimento do HTML5, uma das principais especicaes sobre a tag <video> a interoperabilidade entre CODECs. Neste mbito, o autor ainda continua, citando que a World Wide Web Consortium (W3C), que rgo que publica os padres do HTML, procura publicar somente recomendaes que podem ser implementadas sem o uso de cdigo proprietrio (royalty-free). Ainda, pode-se citar que a diversicao dos navegadores web, fez com que cada um desses apoia-se um ou mais CODECs especcos 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 vdeo diferente, possibilitando que um cdigo HTML seja lido perfeitamente em vrios navegadores atuais, utilizando o arquivo de vdeo alternativo suportado pelo navegador (PFEIFFER, 2010). Ainda nesta perspectiva, Pfeiffer (2010) descreve que existem diferentes formatos de encapsulamento de vdeos disponveis atualmente, e estes formatos, em sua maioria suportam uma grande quantidade de CODECs de udio e vdeo com suporte a taxa de bits variveis, facilitando ainda mais a possibilidade destes serem utilizados para HTTP live Streaming. Mais detalhes sobre CODECs sero abordados no prximo captulo. Pode ser visto, na gura 6, um exemplo de um cdigo HTML5 exemplicando a implementao de arquivos alternativos de um mesmo vdeo. 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 no fazer parte da especicao do HTML5, ainda que se benecie dela, lcito supor que a possibilidade desse suporte se estender entre outros navegadores nitidamente provvel. Essa armao ainda inunciada ao relembrar que a especicao do funcionamento do HLS aberta e ao vermos sua implementao estar presente em uma das verses mais atuais de outro sistema operacional para dispositivos mveis, o Android 3.011 (PFEIFFER, 2010) (KOMATINENI et al., 2011). Ao analisar as informaes ditas acima, pode-se notar que o HTTP Live Streaming possui um grande potencial, alm de estar alinhado com as expectativas propostas neste trabalho.
10 11

Sistema operacional para dispositivos mveis desenvolvido pela Apple Sistema operacional para dispositivos mveis desenvolvido pela Google

36

1 2 3 4 5 6 7 8 9 10 11

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

Figura 6: Exemplo de um cdigo fonte HTML5 com elemento <video>

Fonte: adaptado de Powers (2011, p. 10)

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

2.3

CODECS E CONTINER PARA VDEO STREAMING ADAPTATIVO A palavra CODEC, citada diversas vezes neste trabalho, refere-se a um elemento de

extrema importncia na rea de udio e vdeo para web. Nesta sesso, sero abordados alguns CODECs utilizados na distribuio de vdeo em formato streaming adaptativo. Antes disso, porm, necessrio que se proceda a denio e funcionamento de um CODEC bem como tornar clara a diferenciao entre CODECs e continer de vdeo. Quando se est trabalhando com arquivos de mdia, esses so compostos por dois componentes separados: o CODEC, que a abreviao unio das palavras inglesas compressordecompressor (COmpressor-DECompressor) e o responsvel por codicar e decodicar o uxo de udio e/ou vdeo, e o continer, que considerado uma embalagem da mdia, composto pelos uxos de mdia, informaes sobre os dados e, em alguns casos, metadados. Contineres de vdeo podem suportar, alm dos uxos de mdia, subttulos, legendas e ainda outras informaes necessrias para a execuo e sincronia dos dados (POWERS, 2011). Segundo Powers (2011), o continer de vdeo capaz de envolver vrios CODECs diferentes. O autor cita como exemplo, o continer de cdigo aberto Ogg e tambm o CODEC de cdigo aberto VP8, o qual foi adquirido pela empresa Google em fevereiro de 2010 (PFEIFFER, 2010). Pfeiffer (2010), relaciona alguns exemplos de contineres que podem ser utilizados em streaming adaptativos por possurem a capacidade de lidar com taxa de bits variveis, entre

37

eles: MPEG MP4, Matroska MKV (este servindo como base para o desenvolvimento do formato WebM), e Xiph Ogg. Igualmente, Pfeiffer (2010) arma que so inmeros os CODECs existentes atualmente, e tambm relembra que existem CODECs especcos para udio e vdeo, os quais podem ser combinados durante a criao do arquivo de mdia. Embora seja possvel a utilizao de vrios CODECs em um continer, normalmente so encontrados apenas alguns CODECs especcos em determinados contineres (PFEIFFER, 2010). Como as especicaes do HTML5 ainda esto sendo desenvolvidas, no se chegou a escolha de um CODEC base, para ser apontado pela comisso do W3C, a m de padronizar e tornar possvel trabalhar com um nico CODEC, sabendo que esse ser suportado em todos os navegadores (PFEIFFER, 2010). Pfeiffer (2010) arma que uma boa escolha na especicao do CODEC base muito importante para manter a interoperabilidade, e com isso melhorar a experincia do usurio nal. Armou-se, anteriormente, que a diversicao dos navegadores web, fez com que cada um desses apoie-se em um ou mais CODECs especcos de acordo com seus interesses. Porm, algumas dessas escolhas vai contra o princpio fundamental do HTML5, que utilizar somente componentes que possam ser implementados sem o uso de cdigo proprietrio. 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 utilizao do H.264, necessrio ser pago direitos de royalties, a Google, por sua vez, decidiu por no dar suporte a este CODEC nas verses do seu navegador web, o Chrome. Da mesma forma, o CODEC VP8 que normalmente utilizado no continer WebM, foi escolhido pela Google para ser o padro para seu navegador web, porm no possui suporte no navegador da Microsoft (PFEIFFER, 2010; POWERS, 2011). No quadro 2 exibido um sumrio da situao do suporte nativo de alguns dos principais navegadores web. Quadro 2: Introduo do suporte de vdeo 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 padro para seus navegadores Internet Explorer e Safari. O H.264 um CODEC maduro, trabalhando com compresso de vdeo de alta qualidade, que se tornou popular na

38

Internet, sendo suportado pelo site de compartilhamento de vdeo YouTube, iTunes e tambm um dos CODECs obrigatrios em players Blue-Rays (POWERS, 2011). Powers (2011) relembra que, apesar dos arquivos codicados em H.264 serem distribudos sem custo, as ferramentas utilizadas para codicar e decodicar 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, lder mundial em licenas tecnolgicas alternativas e atual detentora dos direitos de royalties do H.264, informou em fevereiro de 2010 uma nota anunciando que em 2016, tornar livre a utilizao H.264, fornecendo acesso aos seus direitos de patente (OREILLY, 2010). Mesmo com essa armao, no lcito supor que no futuro os papis se invertero, e o H.264 ser o padro ocial para distribuio de vdeo apontado pela W3C, de modo que, outros CODECs esto sendo desenvolvidos e aperfeioados e podem se tornar populares at a data especicada pela MPEG LA. Um destes seria o VP8, apoiado pelo continer WebM, criado primeiramente pela empresa On2 e comprado posteriormente pela Google, que prontamente o liberou como um CODEC de cdigo aberto, livre de cobrana de royalties. Inmeras so as brigas em tribunais e diferenas entre aplicaes pelo motivo de direitos de royalties sobre os CODECs (POWERS, 2011). De acordo com Pfeiffer (2010), com a inteno da Google em liberar o VP8/WebM para uso livre de royalties, empresas como Opera, Mozilla, Adobe, entre muitas outras, sentiramse estimuladas a adotarem esse CODEC como padro para suas aplicaes, visto que o VP8 est muito prximo, em termos de qualidade de vdeo, do H.264 e, por isso, possui grandes chances de ser escolhido para ser o CODEC Base para HTML5. Ainda nesta perspectiva, Pfeiffer (2010) arma que a Google, aos poucos, est conseguindo encorajar outros sites de publicaes de vdeo a utilizarem o WebM/VP8. Alguns dos endereos desses sites podem ser vistos no quadro 3. Outra peculiaridade que pode-se apontar sobre os CODECs de vdeo, que eles podem codicar a mdia com perda (lossy ) e sem perda(lossless). CODECs sem perda preservam todos os dados originais do arquivo aps o seu empacotamento. Ao contrrio dos CODECs com perda, que utilizam tcnicas de compresso com a nalidade de minimizar a quantidade de dados a serem armazenados ou transmitidos pelo computador, isto , diminuir o tamanho do arquivo fsico a ser armazenado ou diminuir o consumo de banda necessria para transmiti-lo (POWERS, 2011). No entanto, Powers (2011) aponta que, somente CODECs com perda so suportados para vdeos HTML5. Acredita-se, face ao que foi exposto, que os CODECs que melhor se aplicam a este estudo, so os desenvolvidos com o princpio de cdigo aberto e livres de royalties, como por exemplo, VP8 e Ogg Theora. Porm, Pfeiffer (2010) informa que atualmente, somente O CO-

39

Quadro 3: Suporte de vdeo HTML5 em alguns sites de vdeo de grandes publicaes (social e comercial)

Quadro adaptado de Pfeiffer (2010, p. 6)

DEC de vdeo H.264 possui suporte para este tipo de contedo audiovisual. Portanto, para possibilitar a compresso de vdeo, sem a necessidade de pagamento de royalties, optou-se pela utilizao da biblioteca de compresso X.264. A biblioteca X.264, com uma comunidade ativa e inovadora de desenvolvedores, um implementao open source de um codicador H.264 e, por isso, utilizado em uma variedade de produtos no comerciais (PFEIFFER, 2010) (WAGGONER, 2009).

40

HTTP LIVE STREAMING

Como descrito no captulo 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 documentao, embora essa ainda encontra-se em andamento. Alm disso, essa tecnologia se benecia das inovaes que esto sendo geradas com o novo padro de HTML, seja para ambientes desktops, seja para dispositivos mveis. O HTTP Live Streaming foi inicialmente desenvolvido pela Apple para permitir que provedores de contedos diversos pudessem enviar contedos audiovisuais para dispositivos por ela desenvolvidos, como, por exemplo, iPhone e iPod. Aps isso, eles desenvolveram a mesma funcionalidade em seu player desktop, o QuickTime, e iniciou-se o desenvolvimento da documentao, enviada ento para a IETF para se tornar um padro de streaming sobre HTTP. Atualmente o HLS possui suporte nativo apenas em dispositivos mveis que utilizam o sistema operacional iOS 3.0 ou superior, e no navegador web Safari utilizando o sistema operacional MAC OS X (APPLE, 2011). Porm, pelo fato de ser uma documentao aberta, novos aplicativos esto sendo desenvolvidos tornando possvel a utilizao 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, necessrio criar uma pgina HTML, nos moldes do HTML5, ou ainda um aplicativo cliente para atuar como receptor dos dados de mdia. Alm disso, necessrio o uso de um servidor web para armazenar os fragmentos de mdia e arquivos manifest, bem como um receptor da mdia original para servir como codicador, gerando os fragmentos de mdia. A m de aprofundar-se no tema, necessrio entender do escopo de seu funcionamento. Apple (2011, p. 11) arma que, conceitualmente, o HTTP Live Streaming consiste em trs partes: a) componente servidor: software responsvel por receber a mdia original, codicla digitalmente e gerar os fragmentos de mdia em um formato adequado para a entrega; b) componente de distribuio: um servidor web padro. Trabalha como responsvel em aceitar as requisies do player cliente e respond-las de acordo com o tipo da requisio; c) software Cliente: o responsvel por avaliar os recursos disponveis no ambiente e determinar a escolha dos arquivos de mdia em sua taxa de bits que melhor se adapte ao cenrio atual. Tambm sua responsabilidade, aps receber o

41

retorno da requisio contendo os arquivos (fragmentos) solicitados, mont-los na ordem correta e apresent-los ao usurio de uma forma contnua. A gura 7 exibe gracamente, por meio de um uxograma, os componentes para a entrega de mdia utilizando HTTP Live Streaming.

Figura 7: Fluxograma do funcionamento da entrega de HTTP Live Streaming

Adaptada de Apple (2011, p. 7)

Tem-se assim o ponto de partida para a compreenso a m de aprofundar-se no funcionamento do HTTP Live Streaming. Para isso, pode iniciar-se pela anlise do primeiro ponto da gerao do contedo para o HTTP Live Streaming, ou seja, pelo componente servidor e a captura da mdia. A mdia utilizada pelo componente servidor pode ser gerada em tempo real, ou ainda ter sido gravada antecipadamente. Para a mdia em tempo real, a Apple disponibiliza uma aplicao denominada Media Stream Segmenter, utilizada via linha de comando. Essa ferramenta capaz de capturar em, tempo real, um uxo de mdia contnuo do tipo MPEG-2 e, em seguida, gerar os fragmentos de mdia necessrios para o streaming adaptativo, bem como os arquivos playlist dos arquivos. Para a mdia previamente gravada, a Apple disponibiliza outra aplicao denominada Media File Segmenter, que, assim como a aplicao para mdia em tempo real, tambm utilizada via linha de comando e gera o mesmo produto nal (APPLE, 2011). Antes de continuar com a anlise entre as duas formas de utilizao do HTTP Live Streaming, faz-se necessrias algumas explicaes.

42

Primeiramente pode-se citar os segmentos gerados pelas aplicaes que, apesar de no ser uma obrigatoriedade, normalmente possuem a extenso .ts (abreviatura de Transport Stream), os quais so fragmentos de igual tamanho de tempo, da mdia original. As URLs relativas de acesso a estes arquivos so inseridas no arquivo playlist, conforme a ordem de criao de cada fragmento. O arquivo playlist, um arquivo do tipo M3U8, uma extenso do formato de lista de reproduo M3U. Arquivos M3U so arquivos de texto simples, que consistem em linhas individuais e cada linha uma URL, ou comea com um smbolo ASCII # (cerquilha) (PANTOS, 2011). Pantos (2011) cita que linhas em branco so ignoradas. O autor tambm descreve que as linhas iniciadas com o smbolo # podem ser comentrios ou tags dentro de um arquivo M3U. Neste caso, a citao de tag em uma linha sempre iniciada com os caracteres #EXT e, por se tratarem de tags que podem indicar uma varivel ou comando ao player de mdia, altamente recomendvel que no existam espaos em branco nestas tags, exceto para os elementos em que explicitamente especicado. As demais linhas so consideradas comentrios e, portanto so ignoradas. No draft do HTTP Live Streaming, so descritas as novas tags para extenso do arquivo M3U8 as quais so utilizadas exclusivamente no software cliente. Um exemplo de um arquivo playlist de HTTP Live Streaming pode ser visto na gura 8.

1 2 3 4 5 6 7 8 9 10

#EXTM3U #EXTXTARGETDURATION: 1 0 #EXTXMEDIA SEQUENCE: 0 #EXTINF : 1 0 , h t t p : / / m i d i a . exemplo . com . b r / segmento0 . t s #EXTINF : 1 0 , h t t p : / / m i d i a . exemplo . com . b r / segmento1 . t s #EXTINF : 1 0 , h t t p : / / m i d i a . exemplo . com . b r / segmento2 . t s #EXTXENDLIST

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 incio da transmisso. J para as transmisses ao vivo, o arquivo atualizado a cada novo fragmento gerado pela aplicao. Neste caso, o cliente faz requisies a cada perodo de tempo, a m 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, verica-se na linha 2 a tag #EXT-X-TARGETDURATION que responsvel por indicar o tempo mximo em segundos dos fragmentos. Essa tag deve

43

aparecer somente uma vez e se aplica a todo o arquivo da lista de reproduo. O valor de tempo indicado aps a tag, e separado pelo caractere : (dois pontos) por um nmero inteiro positivo. Cada URI em um arquivo playlist contm um numero de sequncia nica, e este valor indicado pela tag #EXT-X-MEDIA-SEQUENCE e pode ser visualizada na linha 3 da gura 8. A sua insero no obrigatria, porm, caso no exista sua declarao no arquivo, seu valor automaticamente entendido pelo player cliente como valor zero. Essa tag pode existir somente uma vez no arquivo playlist. O nmero de sequncia de cada URI composto pelo valor da URI anterior acrescida de mais o valor 1 (PANTOS, 2011). Pode-se notar no exemplo da gura 8 a presena da tag #EXTINF. Ela especica a durao em segundos do segmento de mdia que est disposto logo aps a sua declarao no arquivo. Esta tag, aps a sua declarao, recebe o caractere :, e em seguida suas variveis. A primeira varivel obrigatria, composta de um nmero positivo, inteiro ou de notao decimal, indicando o tempo em segundos da durao do fragmento. A segunda varivel, no obrigatria, indica um ttulo informativo para o segmento. Estas variveis so separadas por uma vrgula. Nota-se tambm que a linha 10 possui uma tag especca, indicando o m do arquivo. A tag #EXT-X-ENDLIST indica que nenhuma nova linha, contendo a URL de algum fragmento, ser adicionada no nal do arquivo. Essa tag no pode aparecer mais de uma vez em um mesmo arquivo playlist (PANTOS, 2011). E no caso de um uxo de mdia contnuo em tempo real, a cada novo fragmento gerado, a aplicao deve atualizar o arquivo playlist e somente no nal da transmisso inserir a tag indicando a sua nalizao. Neste mbito, caso o segmentador no esteja no mesmo servidor de distribuio, aps as alteraes feitas e os segmentos gerados, esses devem ser enviados ao servidor de distribuio, utilizando o mtodo comumente conhecido como upload, a m de disponibilizar posteriormente os dados acessveis aos clientes. Consequentemente este processo gera uma latncia, que consiste em uma diferena de tempo entre o acontecimento ao vivo e o tempo em que o cliente est visualizando o contedo gravado sendo distribudo. Apple (2011) cita ainda que a latncia tpica e recomendada de aproximadamente 30 segundos. A partir dessa armao, faz-se apropriada a recomendao de utilizar o segmentador de HLS em um dispositivo com acesso a uma rede mais ampla para a conexo entre ele e o servidor de distribuio, com o intuito de sofrer mnimas oscilaes e proporcionar um uxo constante no streaming ao vivo (APPLE, 2011). Inmeros outros exemplos de tags poderiam ser citados aqui, porm, com apenas essas tags citadas possvel utilizar e vericar o funcionamento de um streaming utilizando o HLS. Ainda sobre a existncia do arquivo playlist, relembra-se da questo de streaming adaptativo. Para o funcionamento da adaptao da mdia, existe a possibilidade da criao de um

44

arquivo de ndice mestre, listando nele outros arquivos playlist alternativos com os fragmentos codicados em taxa de bits diferentes. Para a gerao deste arquivo de ndice mestre, Apple tambm disponibiliza uma aplicao de linha de comando, denominada Variant Playlist Creator, capaz de produzir o arquivo de acordo com os parmetros utilizados (APPLE, 2011). Pode-se visualizar na gura 9 um exemplo de um arquivo de ndice mestre.

1 2 3 4 5 6 7

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

Figura 9: Exemplo de um arquivo .M3U8 com variaes de taxa de bits Igualmente, a gura 10 exibe gracamente o arquivo de ndice mestre apontando para os arquivos playlist alternativos, e esses por sua vez, apontando para os fragmentos de mdia.

Figura 10: Exemplo grco de arquivos de ndice alternativos

Adaptada de Apple (2011, p. 20)

Pode-se visualizar na gura 9 a tag #EXT-X-STREAM-INF. Essa tag responsvel por identicar uma URI como um arquivo playlist e fornecer informaes para a sua correta interpretao pelo player cliente. Ela escrita na linha que antecede a URI do arquivo playlist, e seu valor composto por parmetros e valores especcos que podem ser visualizados no quadro 4. Seu formato de utilizao da seguinte maneira: #EXT-X-STREAM-INF:<lista de atributos separados por vrgulas> (PANTOS, 2011).

45

Quadro 4: Atributos de identicao de URI para tag #EXT-X-STREAM-INF Atributo BANDWIDTH Valor Aceita como valor um nmero inteiro positivo, indicando a maior taxa de bits por segundo dos fragmentos da playlist. Este valor obrigatrio para esta tag. Deve ser um limite superior a taxa de bits dos fragmentos a m de evitar overhead. um inteiro que identica a apresentao dentro do escopo de cada playlist. Este valor pode-se repetir a m de identicar playlists com diferentes codicaes de taxa de bits. Sua presena no obrigatria. Contm valores, envolvidos por aspas () e separados por vrgulas, de nomes de CODECs de mdia descritos de acordo com a ISO. Este parmetro deve ser includo nas declaraes de #EXT-X-STREAM-INF. Indica um valor aproximado da resoluo horizontal e vertical do vdeo presente no arquivo playlist. Sua declarao escrita por dois nmeros inteiros separados pelo caractere x, onde o primeiro valor equivalente a largura e o segundo a altura. Deve corresponder ao valor do parmetro GRUPO-ID da tag #EXT-X-MEDIA que possui valor AUDIO para atributo TYPE, indicando o conjunto de udio que deve ser utilizado para interpretao no momento da reproduo. Deve corresponder ao valor do parmetro GRUPO-ID da tag #EXT-X-MEDIA que possui valor VIDEO para atributo TYPE, indicando o conjunto de udio que deve ser utilizado para interpretao no momento da reproduo.
Quadro atapdato de Pantos (2011)

PROGRAM-ID

CODECS

RESOLUTION

AUDIO

VIDEO

Os arquivos de ndice so normalmente criados pelo segmentador disponvel pela Apple, porm, possvel utilizar segmentadores alternativos para a criao dos fragmentos e arquivos de ndice, desde que esses cumpram com as especicaes do HLS. Por exemplo, para a criao de um arquivo playlist pode ser utilizado um simples editor de texto, listando os fragmentos da srie de mdia (APPLE, 2011). Alm da possibilidade de existir arquivos de ndice alternativos para diferentes larguras de banda, possvel tambm existir arquivos de ndice paralelos em caso de haver falha no arquivo de ndice como, por exemplo, uma resposta negativa do servidor web, assim possibilitando que o player obtenha os fragmentos de um servidor de backup, dando continuidade a reproduo da mdia. O nome dado a essa propriedade de criar arquivos de ndice paralelos em caso de falhas Proteo Failover . A gura 11 exemplica um arquivo de ndice com as URIs alternativas paralelas, indicando um segundo subdomnio.

46

1 3 4 5 6 8 9 10 11

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

14 15 16 17

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

Figura 11: Exemplo de um arquivo .M3U8 com ndices alternativos para Proteo Failover Armou-se, anteriormente, que o HTTP Live Streaming requerer mnimas mudanas na infraestrutura do servidor de distribuio. Estendendo essa armao, Apple (2011) cita que no faz distino de servidor web cache, apenas que este deve ser capaz de aceitar as requisies vindas do cliente e respond-las com o arquivo correto. Em relao a armao de que mnimas mudanas so necessrias, o autor cita que a congurao recomendada e que faz parte destas mnimas mudanas, a especicao do tipo de MIME type, congurado no servidor web, associado aos arquivos .M3U8 e .ts. No quadro 5 possvel vericar essas especaes. Quadro 5: MIME type especco para cada extenso de arquivo Extenso do Arquivo .M3U8 .ts MIME type application/x-mpegURL video/MP2T

Quadro atapdato de Apple (2011, p. 14)

Para servidores que utilizam Apache, caso seja possvel a utilizao de arquivos de congurao a nvel de diretrio, que permitem um gerenciamento descentralizado das conguraes do servidor web, o qual normalmente recebe o nome de .htaccess, a congurao de MIME type no requer mudanas nos arquivos de conguraes padres, bastando apenas adicionar as linhas especcas no arquivo .htaccess que ca geralmente na pasta raiz da URL a ser utilizada na distribuio dos arquivos para HTTP Live Streaming (BRYANT, 2006). Pode-se vericar um exemplo de congurao do arquivo .htaccess na gura 12. Esclarecido esse aspecto, entra-se ento na questo do armazenamento dos fragmentos de mdia gerados pelo segmentador de HLS. A organizao destes arquivos pode ser reali-

47

1 2

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

Figura 12: Fragmento de uma arquivo .htaccess com as linhas de congurao para HTTP Live Streaming zada armazenando-os em pastas separadas, de forma a facilitar as manipulaes dos arquivos por um indivduo humano, quando necessrio. Pois como comentado at ento, relembrando que como se trata de streaming adaptativo, poder existir uma srie de outros fragmentos codicados em taxa de bits diferentes, o que pode, em determinado momento, tornar confusa a manipulao destes arquivos caso no seja realizado uma organizao coerente dentro do servidor de distribuio. Kurose e Ross (2010) enfatizam que as aplicaes de multimdia so sensveis a atrasos e a perda de tolerncia, uma caracterstica diferente para a abordagem de contedo esttico, como imagens e arquivos de texto, por exemplo. Neste sentido, vale ressaltar que o HTTP Live Streaming utiliza-se de contedo esttico, visto que seus arquivos esto previamente salvos no servidor de distribuio. E entendendo este aspecto, ressalta-se tambm a possibilidade de utilizar uma infraestrutura de distribuio melhorada com o intuito de superar possveis obstculos para a entrega dos arquivos de mdia. Infraestrutura esta que, pode ser composta por ns de Content Delivery Network (CDN) que esto localizados prximos aos pontos onde se encontram os usurios nais. Acredita-se que com essas descries dos itens principais que compem o HTTP Live Streaming, podem-se entender as necessidades bsicas para criar um conjunto de arquivos e conguraes capazes de possibilitar a utilizao do HLS. Frente a isso, notrio possuir entendimento tambm de aspectos necessrios para a criao da mdia original at a sua segmentao, que de acordo com a premissa desta pesquisa de possibilitar a utilizao de HTTP Live Streaming em dispositivos mveis, 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 sesso 2.3, pelo fato da codicao de vdeo utilizada para HTTP Live Streaming ser com perda, o vdeo de entrada deve estar em sua melhor qualidade possvel. Portanto, se o vdeo original estiver com uma qualidade considerada baixa, quanto maior a compresso a m de gerar os fragmentos para dispositivos e redes de baixa capacidade, menor ainda ser a qualidade disponvel para os usurios destes dispositivos. Esta compresso basicamente formada pela escolha de alguns fatores como resoluo da tela do

48

dispositivo do usurio, nmero de quadros chaves e taxa de bits, que normalmente so escolhidos com base no pblico formado pelos usurios nais (APPLE, 2011). Apple (2011) exemplica algumas combinaes de fatores para o vdeo nal a ser gerado. Estas combinaes podem ser visualizadas no quadro 6. A combinao adequada para o streaming de dados proporcional a uma boa experincia do usurio. Quadro 6: Exemplos de combinaes de fatores para compresso de dados para HLS Conexo Celular Celular Celular Wi Wi Wi Celular Celular Celular Wi Wi Resoluo de tela 480 x 224 480 x 224 480 x 224 640 x 360 640 x 360 960 x 540 480 x 300 480 x 300 480 x 300 640 x 480 1280 x 960 Taxa de bits 150 kpbs 200 kpbs 440 kpbs 640 kpbs 1024 kpbs 1840 kpbs 150 kpbs 200 kpbs 440 kpbs 640 kpbs 4540 kpbs Keyframes 30 45 90 90 90 90 30 45 90 90 90 Proporo de tela 16:9 16:9 16:9 16:9 16:9 16:9 4:3 4:3 4:3 4:3 4:3

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

Apple (2011) contnua ainda descrevendo que, independente da velocidade de conexo, recomendvel que exista mais de um arquivo de ndice mestre composto por taxas de uxo de bits variveis, garantindo assim uma boa experincia ao usurio. O autor ainda indica algumas taxas recomendadas, como 150kbp/s para conexes de celular e 240kbp/s para conexes Wi, porm vale ressaltar novamente que estes valores podem variar de acordo com o pblico nal que utilizar do streaming de mdia. Ainda nessa perspectiva, arma-se ainda que a m congurao do arquivo de ndice como, a tag BANDWIDTH (vericada no quadro 5) pode fazer com que o vdeo no reproduza suavemente, causando pausas constantes ou ainda no 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 suciente para a perfeita reproduo do streaming. Apple (2011) arma que altamente recomendado que exista um uxo de mdia alternativo, com uma taxa de 64kpb/s ou menor para que, em condies adversas de uma rede de celular onde a velocidade da conexo car comprometida, seja possvel ainda uma execuo constante da mdia. Caso no seja possvel gerar um vdeo com uma qualidade aceitvel, o autor ainda indica que haja um streaming somente com udio e com uma imagem xa. Neste caso indicado que para uma conexo de celular, o vdeo seja preparado com resoluo 400 x 224 para uma proporo de 16:9 e 400 x 300 para uma proporo 4:3.

49

3.1

CODIFICANDO ARQUIVOS DE VDEO COM FFMPEG As ferramentas criadas pela Apple para auxiliarem na produo 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 utilizao de softwares de cdigo fonte aberto, e como consequncia a escolha de uma ferramenta para codicao de mdia que possa estar disponvel a todos. Com esta convico, escolheuse a utilizao do aplicativo FFmpeg, que uma ferramenta de linha de comando, capaz de converter mdias 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 opes de compilao escolhidas1 . Alm disso, seus arquivos binrios so compatveis com a maioria das plataformas, o tornando assim um software com uma interoperabilidade incrivelmente satisfatria para o propsito desta pesquisa. Pela sua notria capacidade, vrios outros softwares com interface grca foram desenvolvidos para se beneciar do seu poder de converso de mdia com o intuito de criar aplicaes de fcil utilizao para os usurios nais. Como descrito na sesso 3.1, a melhor soluo para a tarefa de codicao do contedo audiovisual seria utilizando CODEC de vdeo VP8. Porm, pelo fato de no haver um padro denido, opta-se pela utilizao do CODEC H.264 para a codicao e gerao dos vdeos e fragmentos necessrios para HTTP Live Streaming. Existem vrias ferramentas capazes de criar ou converter vdeos para H.264, porm como descrito na sesso 2.3, optou-se pela utilizao de uma biblioteca livre, que recebe o nome de X.264. A biblioteca X.264 publicada pela licena General Public License (GNU). Para sua utilizao no FFmpeg, essa biblioteca chamada pelo apelido libx264. Sua utilizao por linha de comando permite a insero de inmeras opes de codicao, possibilitando uma enorme gama de possibilidades para a gerao de vdeos codicados para streaming. Um modelo de sintaxe de utilizao do FFmpeg, que igual para ambas as verses de compilao para diversos sistemas operacionais, pode ser visualizada na gura 13. Como padro 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 cdigo fonte do FFmpeg com apenas algumas bibliotecas especcas, por motivo de compatibilidade, alm de demonstrar de fato a possibilidade de portabilidade da aplicao e sua facilidade para uso nal, optou-se por utilizar a verso Static do FFmpeg. A verso Static, uma aplicao j compilada com vrias outras bibliotecas de converso de mdia incluMais informaes sobre licenas do FFmpeg podem ser visualizadas na pgina de Consideraes Legais do projeto: http://ffmpeg.org/legal.html
1

50

sas. A compilao utilizada para este trabalho foi publicada em 31 de dezembro de 20112 do FFmpeg, atualmente a ltima verso estvel disponvel (FFMPEG, 2011).

ffmpeg . exe [ opes g l o b a i s ] [ [ opes do a r q u i v o de e n t r a d a ] [ -i arquivo de entrada ] ] . . . { [ opes do a r q u i v o de sada ] arquivo de sada } . . .

Figura 13: Modelo da sintaxe genrica para FFmpeg Com as informaes colhidas para esta pesquisa sobre os CODECs de converses, presentes na sesso 3.1, juntamente com os dados para as combinaes de fatores para compresso de dados indicados pela Apple (2011), torna-se possvel, utilizando o FFmpeg, gerar novos vdeos com qualidades diferentes para a utilizao em ambientes e velocidades de conexes diferentes. O quadro 7 exibe algumas opes, que podem ser utilizadas como parmetro para a gerao destes novos arquivos. A lista completa de parmetros que podem ser utilizados pode ser visualizado na documentao online do FFmpeg3 . A sequncia das opes na montagem da linha de comando para a converso deve ser escrita cuidadosamente, pois, cada uma das opes interfere na sua opo posterior, tanto para o arquivo de entrada como para o arquivo de sada. Uma opo pode aparecer mais de uma vez em um mesmo comando. Estas regras no se aplicam as opes globais, que so declaradas em primeiro lugar na linha de comando. Todos os parmetros que aceitam um valor numrico podem aceitar um valor de texto contendo suxos de acordo com o International System of Units (SI), por exemplo, Kb,Mb, Gb (FFMPEG, 2011). Com base do modelo do comando presente na gura 13, juntamente com alguns modelos de parmetros que podem ser visto no quadro 7, possvel criar uma linha de comando, simples, capaz de realizar uma converso. Essa armao pode ser conrmada ao vermos uma linha de comando, presente na gura 14, para a converso de um vdeo original em formato .avi para um formato .ts. Algumas combinaes de parmetros so muito importantes para a converso de vdeo que utilizado em streaming de dados, como por exemplo, a possibilidade de indicar a taxa mxima e mnima de bits variveis. Essa declarao se d pela utilizao dos parmetros qmax e -qmin. Declarar o valor da taxa de bits variveis, tambm conhecido na rea de vdeo digital como Variable Bit Rate (VBR) ou ainda como Taxa de uxo de dados varivel, permite ao codicador aproveitar o mximo possvel cada espao de tempo. Assim, por exemplo, se no indicado um valor mnimo, o codicador ir reduzir um espao de tempo que possui um silncio extremo em um udio, a um valor de 1Byte/s, que corresponde a 8bit/s. O mesmo pode ocorrer
2 3

Compilao 8475ec1 A documentao online do FFMPEG acessvel pela URL: http://ffmpeg.org/ffmpeg.html

51

Quadro 7: Exemplos de opes de parmetros para converso de vdeo utilizando FFmpeg Parmetro Exemplo -i -i VideoOriginal.avi -ss -ss 0 Detalhes Informa o caminho fsico do arquivo original a ser utilizado Busca uma determinada posio de tempo e utiliza como ponto inicial do vdeo, ignorando o espao de tempo anterior, dentro do arquivo de entrada. Caso sua declarao seja feita nas opes do arquivo de sada, essa posio obtida do arquivo codicado e, como consequncia, possui uma maior preciso. Seu valor pode ser um numero inteiro ou de ponto utuante, indicando os segundos, ou um valor de texto com padro hh:mm:ss[.xxx] Indica que o aplicativo deve parar de escrever o arquivo de sada aps alcanar o valor de tempo denido nesse atributo. Seu valor pode ser um numero inteiro ou de ponto utuante, indicando os segundos, ou um valor de texto com padro hh:mm:ss[.xxx] Dene o tamanho da resoluo Dene a proporo de tela (aspect ratio) Dene a taxa de bits a ser utilizada. Pode ser declarada acompanhando as letras especcas para especicar qual mdia deseja-se atribuir o valor. (:v refere-se a vdeo e :a refere-se a udio) Dene o tamanho do buffer de vdeo (em bits) Dene o valor mximo de taxa de bits de vdeo (em bit/s). Exige que seja declarado o parmetro -bufsize na mesma linha de comando Dene a taxa de quadros por segundo (fps). Dene a tolerncia da taxa de bits (padro 4000k). Este valor dene quo longe a taxa de controle pode desviar da taxa de bits mdia. Dene a frequncia do udio (Hz) Dene a taxa mxima da escala do quantizador (VBR) do vdeo (bit/s) Dene a taxa mnima da escala do quantizador (VBR) do vdeo (bit/s) Dene CODEC de vdeo a ser utilizado Dene CODEC de udio a ser utilizado Entende-se como forar o formato de entrada ou sada. Normalmente, o formato detectado automaticamente, o que torna essa opo desnecessria na maioria dos casos

-t

-t 10

-s -aspect -b

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

-bufsize -maxrate

-r -bt

-r 24 -bt 200k

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

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

Adaptado a partir de (FFMPEG, 2011)

52

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

Figura 14: Modelo da sintaxe genrica para FFmpeg em um espao de tempo, em um vdeo no caso, em que necessrio uma taxa muito maior, e ento o codicador, utilizando o valor congurado atravs do parmetro de valor mximo, limita essa taxa. A importncia dessa possibilidade est associada ao caso de um mesmo vdeo possuir espaos de tempo e que nenhuma ou mnimas informaes so necessrias, 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 consequncia maior o tamanho fsico do arquivo. Da mesma forma, quando menor o bitrate, menor a qualidade e ento menor o tamanho fsico do arquivo (FFMPEG, 2011) (WAGGONER, 2009). Muitos outros parmetros poderiam ser citados aqui, porm dentre estes citados at ento, proporcionam um bom grupo de opes para gerao de vdeos para HTTP Live Streaming. As bibliotecas de converso em sua maioria possibilitam a utilizao de parmetros prprios, capazes de manipular ainda outros aspectos para gerao do vdeo nal. Um bom exemplo que pode-se destacar, dentro da biblioteca X.264, a possibilidade de indicar ao aplicativo conversor a denio de espao de macroblocos diferentes, atravs da utilizao do parmetro -partitions. Com essa denio de macroblocos, o aplicativo de converso de vdeo consegue aperfeioar a qualidade, removendo bits de partes da imagem que tem menor impacto em longo prazo, como detalhes de transio que duram apenas alguns frames, gerando uma grande ecincia de processamento e melhorias para vdeo nal gerado (MANZATO, 2006) (WAGGONER, 2009). Entre tantos parmetros que proporcionam melhorias no produto nal a ser visualizado pelo usurio, existem dois parmetros que, utilizados em conjunto, possibilitam a criao dos fragmentos de vdeo que so utilizados no HTTP Live Streaming, e assim no gerando a necessidade de utilizar outros aplicativos para os cortes do contedo audiovisual. O parmetro -ss indica um tempo inicial, a partir do qual o codicador deve iniciar a leitura, e juntamente com o parmetro -t indica qual o espao de tempo, a partir do ponto indicado por -ss, o codicador deve parar de ler e escrever o arquivo de sada. Dessa maneira, utilizando apenas um arquivo de lote (batch), possvel realizar a diviso do vdeo em pequenos pedaos. Pode-se vericar um exemplo de um arquivo de lote, especicamente um arquivo .bat para sua execuo em ambiente Windows, na gura 15. O cdigo exemplicado na gura 15, ao ser executado gera-

53

ria um fragmento de vdeo de 10 segundos do vdeo original, e o convertendo para o formato especco utilizado no HTTP Live Streaming.

1 2

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

Figura 15: Exemplo de um arquivo batch para a fragmentao de vdeo utilizando FFmpeg Uma vez, sabendo como realizar a diviso dos fragmentos de vdeo, possvel, atravs de linguagens de script com a possibilidade de manipulao de arquivos no ambiente executado, criar tarefas automatizadas para a gerao dos fragmentos de vdeo nais, bem como os arquivos playlist. Para validao dessas armaes, optou-se por desenvolver um exemplo funcional, utilizando linguagem script Hypertext Preprocessor (PHP), de um fragmentador de vdeo utilizando FFmpeg. Utilizando como ambiente, um servidor web com sistema operacional Windows e Apache e PHP instalado, foi possvel a criao de um script PHP demonstrativo (Apndice A) para a automatizao da tarefa de criar os fragmentos de vdeo juntamente com seu arquivo playlist correspondente. Este script consiste em uma classe, contendo parmetros com valores pr-denidos para a converso de vdeo, alm de tambm ser possvel a passagem de novos parmetros para denir outros valores. Estes parmetros, juntamente com os seus respectivos valores, so utilizados especialmente em uma linha de comando repassado ao executvel do FFmpeg, sendo ele capaz de gerar os fragmentos necessrios. Cabe neste momento, uma breve descrio de como a operao do script PHP, que, para ns didticos desta pesquisa, optou-se por nome-lo somente como PHP HLS Fragmenter . Ao ser instanciado a classe do PHP HLS Fragmenter , atribuindo uma nova varivel criando um novo Objeto, se faz necessria a passagem de parmetros obrigatrios. O primeiro parmetro o caminho do vdeo de entrada a ser convertido, que deve estar armazenado no mesmo dispositivo que est sendo executado o script. O vdeo de entrada pode estar na pasta input, que especca para organizao dos arquivos que sero manipulados pelo PHP HLS Fragmenter , ou ento em qualquer outra pasta do sistema e que esteja acessvel pelo PHP HLS Fragmenter . Porm neste caso, h a necessidade de ser passado como parmetro o caminho completo ou relativo do vdeo de entrada. Existem ainda dois outros parmetros a serem passados, ambos so obrigatrios, porm passando o segundo parmetro, que o nome de um dos pers com parmetros j denidos dentro do PHP HLS Fragmenter , o terceiro torna-se opcional, pois trata-se de novos atributos.

54

Neste momento, aps a nova criao do objeto, o PHP HLS Fragmenter realiza algumas operaes como, encontrar o arquivo de vdeo e vericar sua existncia, congurar as variveis de ambiente e obter informaes do arquivo de entrada. Caso alguma das operaes falhe, um arquivo de texto em formato de log, gerado na pasta raiz, onde est sendo executado o script, a m de facilitar correes de conguraes. Aps as conguraes, basta realizar a chamada da funo especca para iniciar o procedimento de converso e fragmentar o vdeo, bem como a criao do arquivo playlist. Utilizando um arquivo de vdeo de entrada, contendo um tempo total de 00:04:13.36 (253.36 segundos), o script PHP gerou 26 fragmentos de vdeo (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 vdeo escolhido no era valor mltiplo de 10. Como padro para criao das pastas para organizar os fragmentos de vdeos gerados, adotou-se utilizar o valor do parmetro -maxrate como nomenclatura. Desta forma, ao ser gerado os fragmentos diferentes para um mesmo vdeo, o script criar pastas especcas para cada grupo de fragmentos, dentro da pasta output, com o valor de -maxrate. Os fragmentos, por sua vez, recebem como nome um prexo, precedido do nmero do fragmento, juntamente com a terminao .ts. Da mesma forma, o arquivo playlist M3U8, tambm recebe o nome de acordo com o valor -maxrate, e por padro salvo na pasta output. Assim sendo facilmente criado uma estrutura organizada para facilitar a manipulao do conjunto de todos os arquivos gerados na operao, que pode ser visualizada na gura 16.

Figura 16: Exemplo de organizao de pastas criadas pelo PHP HLS Fragmenter De acordo com o que foi exposto, foi possvel criar verses do mesmo segmento para taxas de bits diferentes, como 88kpb/s, 206kpb/s e 728kpb/s utilizando o PHP HLS Fragmenter . Pode ser vericado no apndice 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 informaes necessrias para ento criar um conjunto de vdeos alternativos para um streaming utilizando HTTP Live Streaming. Aps a criao dos fragmentos pelo PHP HLS Fragmenter , h a necessidade da criao do arquivo de ndice mestre manualmente. O exemplo do arquivo mestre nal pode ser vericado na gura 17.

1 2 3 4 5 6 7

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

Figura 17: Arquivo mestre nal, criado para utilizar os arquivos gerados pelo PHP HLS Fragmenter Com os fragmentos de vdeos, juntamente com os arquivos playlists, arquivos de ndice e um arquivo HTML, necessrio torn-los disponveis a partir de uma URL. Para tal, preciso mover a estrutura do conjunto de arquivos gerados para um servidor web cache como, por exemplo, um servidor Apache, que receber as requisies da aplicao cliente. Sendo realizado as atividades como descritas anteriormente, a congurao do servidor web que pode ser visto na gura 12, e criado o arquivo HTML contando as informaes com a tag <video> e armazen-lo juntamente na pasta acessvel do servidor web cache, acredita-se que o componente de distribuio est preparado. Para a validao desse resultado obtido da converso e fragmentos do vdeo original, foi utilizado um navegador web Safari, em um ambiente Mac OS X Lion. Ao se acessar a URL contendo o arquivo HTML (Apndice C), com a tag <video> apontando para o arquivo de ndice, o vdeo inicia sua reproduo buscando cada fragmento, sequencialmente, do servidor. Como dito anteriormente, de acordo com a possibilidade de maior taxa de transferncia da rede, e de acordo com o consumo de processamento no ambiente do dispositivo que est reproduzindo o vdeo, o player ento busca os fragmentos indicados com maior qualidade ou menor, de acordo com a deciso do player. Um exemplo dessa troca de qualidades pode ser vista no log de acesso do servidor web cache, exibido no Apndice 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 usurio. Face ao que foi exposto, pode-se entender que a aplicao responsvel pela recepo da mdia original, sendo ela gravada ou ao vivo, e a converter para o formato funcional para

56

HTTP Live Streaming, alm de fragmentar e gerar seu arquivo playlist respectivo, considerada o objeto principal de uma ferramenta para criao de ambientes que utilizem Streaming Adaptativo, principalmente no mbito do HTTP Live Streaming. Diversas so as possibilidades de desenvolvimento de aplicaes para tal funcionalidade, desde que se mantenham os princpios necessrios para seu funcionamento. As atribuies de novas funcionalidades, como interface grca, organizador e manipulador automtico de pastas, gerao de arquivos de ndices, entre outros, podem enriquecer ainda mais as ferramentas a serem desenvolvidas para a criao de streaming de vdeo utilizando HTTP Live Streaming e facilitar a utilizao dessas pelos usurios nais.

57

CONCLUSO

Este estudo abordou aspectos relevantes da tecnologia streaming, utilizando a adaptabilidade como rea de pesquisa dentre as inmeras possibilidades existentes para a distribuio de contedos audiovisuais dentro dessa tecnologia. Aprofundou-se no entendimento de um mtodo relativamente novo de distribuio adaptativa, chamado de HTTP Live Streaming, desenvolvida pela empresa Apple, capaz de realizar a adaptao sem a necessidade de aplicaes especcas para a distribuio de streaming. Com o intuito de estudar os mtodos de distribuio de vdeo, durante o desenvolver deste trabalho, foi necessrio efetivar uma pesquisa para levantar os fatores que tornaram o Streaming por HTTP popularmente conhecido. Um estudo completo em pesquisas bibliogrcas sobre mtodos e tecnologias de distribuio de vdeo, foi desenvolvido a m de criar denies de streaming, bem como a explicar os trs principais mtodos de distribuio desta tecnologia: Streaming Tradicional, HTTP Progressive Download e HTTP Streaming. Este estudo foi capaz de descrever as denies de HTTP Streaming Adaptativo, e desta forma, possibilitar um bom entendimento do HTTP Live Streaming, o qual faz parte deste mtodo de distribuio. Apresentou-se ainda, alguns comparativos entre outras tecnologias que utilizam a adaptao como o mtodo principal de distribuio. Embora no fosse o foco principal deste trabalho, fez-se necessrio um breve levantamento de CODECs e contineres de vdeos, para utilizao de HTTP Live Streaming. Por se tratar de um mtodo recente, o HTTP Live Streaming possui um nmero limitado de trabalhos cientcos em sua rea. Para tal, houve a necessidade de leituras em manuais e documentaes, a m de tornar possvel o entendimento do seu funcionamento, para a aplicao 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 no puderam ser alcanados dentro desta pesquisa, como, por exemplo, levantar os requisitos necessrios para um sistema de captura de udio e vdeo. Com o intuito de criar um estudo em potencial, capaz de minimizar as necessidades de aplicaes e conhecimentos avanados para a distribuio de streaming, a implementao deste estudo baseando-se em diversos sistemas operacionais, tornou-se invivel no decorrer deste trabalho. Com base em referncias analisadas para a elaborao deste estudo, pode-se observar claramente a potencialidade do mtodo de distribuio HTTP Live Streaming. Apesar de sua aplicao ainda estar limitada a dispositivos com sistemas operacionais desenvolvidos pela empresa Apple, foi possvel encontrar outros desenvolvedores inserindo este mtodo nativamente em seus sistemas operacionais. Por sua documentao estar disponvel atravs de um draft

58

de RFC, apesar de extensa, facilmente entendvel seu funcionamento, tornando possvel a criao de novas aplicaes capazes de suportar tal mtodo de streaming. Como exemplo, neste trabalho foi apresentado um prottipo funcional como parte de um produto completo, o qual capaz de obter uma mdia previamente gravada, e prepar-la para distribuio utilizando aplicativos e bibliotecas de cdigo aberto. O HTTP Live Streaming, desenvolvido para utilizar-se das novas possibilidades de insero de vdeo em pginas web que utilizam HTML5, tornando assim pelo cliente, a execuo dos contedos enviados pelo servidor de distribuio, facilmente visualizado sem a necessidade de instalao de plugins ou aplicaes adicionais. Mesmo que esta verso do HTML ainda no esteja totalmente publicada, seu estudo potencialmente vlido, pois se trata de uma atualizao global da atual verso do HTML, utilizado nos principais navegadores. Apesar das diculdades encontradas para o desenvolvimento da aplicao proposta neste trabalho, o objetivo geral foi alcanado, pois foi possvel expor o funcionamento do mtodo HTTP Live Streaming, bem como entender o ambiente necessrio para seu funcionamento, e ainda com propsito de uma soluo com base cdigo aberta, sem custo com royalties. Com esses resultados, acredita-se que o HTTP Live Streaming uma poderosa ferramenta de distribuio de streaming. Por este motivo, apontam-se possveis trabalhos futuros, a m de elaborar solues completas para este mtodo, incluindo ferramentas multiplataformas com possibilidade de usar canais de entrada de vdeo, gravado em outro perodo temporal ou ao vivo.

59

REFERNCIAS ADAO, C. M. C. de J. Tecnologias de Streaming em Contextos de Aprendizagem. 2006. Dissertao de Mestrado (Mestre em Sistemas de Informao) - Departamento de Sistemas de Informao, Universidade do Minho, Guimares, PT, 2006. ADOBE, D. M. G. A Streaming Media Primer. 2001. Adobe Systems, Inc. Disponvel em: <http://goo.gl/WSW9L>. Acesso em: 18 de set. de 2011. ADOBE, S. I. HTTP Dynamic Streaming on the Adobe Flash Platfor. 2010. Disponvel em: <http://goo.gl/29nlw>. Acesso em: 20 de set. de 2011. ADOBE, S. I. Perguntas frequentes sobre HTTP Dynamic Streaming. 2011. Disponvel em:

<http://goo.gl/7EGhm>. Acesso em: 26 de set. de 2011.

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

60

KOZAMERNIK, F. Media Streaming over the Internet an overview of delivery technologies. 2002. EBU Technical Department. KUROSE, J. F.; ROSS, K. W. Computer networking: a top-down approach. 5. ed. Boston, MA: Pearson Education , Inc, 2010. LARSON, L.; COSTANTINI, R. Flash Video for Professionals: Expert Techniques for Integrating Video on the Web. Indianapolis, Indiana: Wiley Publishing, Inc., 2007. ISBN: 978-0-470-13113-8. LIM, Y.; SINGER, D. RFC 4337: MIME Type Registration for MPEG-4. Fremont, California, USA, March 2006. MACDONALD, M. Pro Silverlight 3 in VB. [S.l.]: Apress, 2009. (Apress Series). ISBN 9781430224273. MANZATO, M. G. Tcnicas e Padres de Codicao de Vdeo. 2006. Trabalho de Concluso de Curso (Bacharel em Cincia da Computao) - Departamento de Computao, Universidade Estadual de Londrina, Londrina, PR, 2004. MICROSOFT, C. Smooth Streaming. 2011. Disponvel em: <http://goo.gl/BQX89>. Acesso em: 18 de set. de 2011. MITCHELL, J. L. MPEG video compression standard. Norwell, MA: Kluer Academic Publishers, 2000. OREILLY, T. MPEG LA News Release. 2010. Disponvel em: <http://goo.gl/lVv1V>. Acesso em: 16 de out. de 2011. PANSANATO, G. C. Anlise detalhada de CODECS e estudos relacionados. 2005. Relatrio de Estgio Curricular (Bacharelado em Cincia da Computao) - Universidade Estadual de Londrina, Londrina - SC. PANTOS, E. R. Internet-Draft: HTTP Live Streaming (work in progress). Fremont, California, USA, September 2011. Expira em: 2 de Abril de 2012. PFEIFFER, S. The Denitive Guide to HTML5 Video. [S.l.]: Apress, 2010. (Denitive Guide Series). ISBN 9781430230908. POWERS, S. HTML5 Media. [S.l.]: OReilly Media, 2011. ISBN 9781449315313. RICHARDSON, I. E. G. H.264 and MPEG-4 Video Compression: Video Coding for Next Generation Multimedia. Southem Gate, Chichester, West Susex PO19, England: John Wiley I& Sons Ltd. The Atrium, 2003. ISBN: 0 4708483-7-5. SAMPAIO, C. JAVA - ENTERPRISE EDITION 6: DESENVOLVENDO APLICAOES CORPORATIVAS. BRASPORT, 2011. ISBN 9788574524603. Disponvel 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 Visualizao de Sesses de Colaborao Multimdia. 2010. Dissertao de Mestrado em Engenharia Informtica - Universidade Nova de Lisboa Faculdade de Cincias e Tecnologia Departamento de Informtica, 2010. THORNHILL, S.; ASENSIO, M.; YOUNG, C. Video Streaming: a guide for educational development. PO Box 88, Manchester: The JISC Click and Go Video Project, ISD, UMIST, 2002. ISBN: 0 9543804-0-1. TIWARI, S.; ELROM, E. AdvancED Flex 4. New York, NY: Springer Science Bussines Media LLC., 2010. ISBN: 978-1-4302-2484-6. WAGGONER, B. Compression for Great Video and Audio: Master Tips and Common Sense. [S.l.]: Elsevier Science & Technology, 2009. (DV Expert Series). ISBN 9780240812137. ZAMBELLI, A. IIS Smooth Streaming Technical Overview. 2009. Media Technology Evangelist. Disponvel 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

APNDICES

63

APNDICE A - SCRIPT PHP PARA GERAO DE FRAGMENTOS COM FFMPEG

1 3 5 7 8 9 10 11 13 14 15 17 19 21 22 23 24 25 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53
<?php

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

c l a s s FFmpeg_HLS_conversion_test {

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

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

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

= NULL ; = 10; = NULL ;

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

= NULL ;

v a r $getID3

= NULL ;

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

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

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

"mobile_16x9_128k"

=> A r r a y (

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

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

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

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

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

64

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

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

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

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

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

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

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

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

$ t h i s >getID3 = new getID3 ;

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

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

65

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

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

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

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

/ / $param / / $value

string string

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

/ / $inputFile

string

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

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

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

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

/ / $profileName

string

p r o f i l e name

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

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

66

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

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

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

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

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

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

67

215 216 217 218 219 220 221 222 223 225 226

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

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

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

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

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

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

$ t h i s >make_HeaderPlaylist ( ) ;

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

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

68

266 267

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

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

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

$fragment . "\"" ) ;

268 269 270 271

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

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

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

$fragment . "\"" ) ;

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

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

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

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

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

285 286 288 289

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

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

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

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

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

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

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

//

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

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

69

310 311 312 313 314 315 316 317

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

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

APNDICE B - SCRIPT PHP PARA CHAMADA A BIBLIOTECA PHP HLS FRAGMENTER

1 2 4 5 7 8 10 11 13
<?php include "includes/ffmpeg_HLS_conversion.php" ;

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

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

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

?>

APNDICE C - CDIGO HTML5 CONTENDO CHAMADAS AO ARQUIVO DE NDICE HLS

1 2 3 4 5 6 7 8 9 10 11
<html> <head> < t i t l e >Test < / t i t l e > <meta name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable

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

70

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