Embed Size (px)
Citation preview
CENTRO UNIVERSITÁRIO UNIVATES CURSO DE ENGENHARIA DA COMPUTAÇÃO
Armando Taffarel Neto
ESTUDO E DESENVOLVIMENTO DE UMA SOLUÇÃO BASEADA EM PADRÕES ABERTOS PARA SINCRONIZAÇÃO DE SLIDES COM
STREAMING DE ÁUDIO E VÍDEO
Lajeado, dezembro de 2007
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Armando Taffarel Neto
ESTUDO E DESENVOLVIMENTO DE UMA SOLUÇÃO BASEADA EM PADRÕES ABERTOS PARA SINCRONIZAÇÃO DE SLIDES COM
STREAMING DE ÁUDIO E VÍDEO
Trabalho de conclusão de curso apresentado ao Centro Universitário UNIVATES para a obtenção do título de Bacharel em Engenharia da Computação. Orientador: Marcelo de Gomensoro Malheiros
Lajeado, dezembro de 2007
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
AGRADECIMENTOS
Ao meu orientador, professor Marcelo de Gomensoro Malheiros, pela sugestão do
tema, pela dedicação e pela grande ajuda em todas as fases do trabalho. Ao professor Ronaldo
Hüsemann, pela grande disponibilidade em ajudar e contribuir e pelas orientações que foram
fundamentais em vários momentos. A todos os professores do curso de Engenharia da
Computação, que de uma forma ou de outra contribuíram para a realização deste trabalho,
seja de forma direta ou indireta.
Aos meus pais Sueli e Flávio, e às minhas irmãs, Flávia e Mariana, pelo incentivo e
pela infraestrutura, sempre presentes e atuantes e nunca medindo esforços para ajudar quando
necessário, sempre da melhor forma possível.
À minha namorada Lisandra, que sempre esteve ao meu lado me apoiando, me
cuidando e me dando forças para seguir sempre em frente, suportando noites mal dormidas
por causa dos estudos e tolerando minhas ausências.
Aos meus amigos, sempre presentes, compartilhando idéias e emoções e ajudando a
esfriar a cabeça quando ela superaquecia com os estudos.
Aos meus colegas formandos de Engenharia da Computação, pela corrente positiva
que nos fez chegar até aqui. TEM QUE SER!
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
RESUMO
Este trabalho apresenta uma solução para sincronização de slides com um streaming de áudio e vídeo utilizando apenas tecnologias livres de patentes e de código fonte aberto. O objetivo principal é simular virtualmente um ambiente nãointerativo de sala de aula. A solução contempla os quatro estágios de streaming: captura, codificação, distribuição e visualização. Ela foi desenvolvida combinandose uma série de tecnologias existentes e adaptandose algumas delas. Diversos testes foram feitos e diferentes cenários foram simulados com o intuito de construir uma solução flexível e robusta. Desta forma, este trabalho pretende contribuir para o crescimento do ensino à distância, especialmente no que diz respeito ao uso de soluções livres.
Palavraschave: streaming, slides, sincronização, ensino à distância
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
ABSTRACT
This work presents a solution for the slide synchronization with audio and video streaming only using patentfree and open source technologies. The main goal is to virtually simulate a noninteractive classroom environment. The solution comprises the four stages of streaming: capture, coding, distribution and visualization. It was developed combining a set of existing technologies and adapting some of them. Several tests were made and various setups were simulated aiming to build a flexible and robust solution. Therefore, this work wants to contribute for the distance learning expansion, specially regarding to the use of free solutions.
Keywords: streaming, slides, synchronization, distance learning
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE SIGLAS E ABREVIATURAS
AVC Advanced Video Coding
bps bits por segundo
CBR Constant Bit Rate
HTML HyperText Markup Language
IP Internet Protocol
ITU International Telecommunications Union
MSE Mean Squared Error
NTSC National Television Standards Committee
PAL Phase Alternation by Line
PPM Portable PixMap
PSNR Peak Signal-to-Noise Ratio
RGB Red Green Blue
RLE Run-Length Encoding
SECAM Sequential Color and Memory
VBR Variable Bit Rate
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE FIGURAS
FIGURA 1 Os padrões RGB e YUV......................................................................................22
FIGURA 2 Uma onda de som é digitalizada usando amostragem discreta............................23
FIGURA 3 – O modelo cliente/servidor...................................................................................34
FIGURA 4 – O streaming como uma alternativa para transmissão multimídia.......................37
FIGURA 5 Os quatro estágios do streaming..........................................................................38
FIGURA 6 O streaming desde a captura até a visualização...................................................41
FIGURA 7 Streaming em temporeal.....................................................................................42
FIGURA 8 Streaming sobdemanda.......................................................................................43
FIGURA 9 Reprodução de multimídia via streaming ...........................................................44
FIGURA 10 – Taxa de bits varíavel e constante......................................................................46
FIGURA 11 – O Gstreamer perante seus plugins e outras aplicações......................................58
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
8
FIGURA 12 – Interligação de elementos do Gstreamer...........................................................59
FIGURA 13 – Representação de pipeline para reproduzir Ogg com vídeo e áudio.................59
FIGURA 14 – Exemplo de tela de administração do Flumotion..............................................62
FIGURA 15 – Tela de demonstração do Adobe Acrobat Connect Professional......................67
FIGURA 16 – Tela de demonstração do Microsoft Office Live Meeting................................68
FIGURA 17 – Tela de demonstração do Wimba Classroom....................................................69
FIGURA 18 – Tela de demonstração do LearnLinc.................................................................70
FIGURA 19 – Esquema para capturar a saída de vídeo do computador..................................74
FIGURA 20 – Esquema para capturar o ambiente compartilhado via RFB.............................76
FIGURA 21 – Esquema para capturar o ambiente compartilhado via chamadas ao modo
gráfico do GNU/Linux..............................................................................................................77
FIGURA 22 – Exemplos de conversores de vídeo...................................................................83
FIGURA 23 – Applet Cortado adaptado...................................................................................97
FIGURA 24 – Comparação do PSNR do vídeo dos slides entre as três formas de captura. . .109
FIGURA 25 – Comparação do PSNR do vídeo dos slides entre as três formas de captura com
base na taxa de bits..................................................................................................................110
FIGURA 26– Comparação da taxa de bits do vídeo dos slides entre as três formas de captura
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
9
com base na codificação VBR................................................................................................111
FIGURA 27– Comparação do uso de processamento entre as três formas de captura usando
VBR e CBR.............................................................................................................................112
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE TABELAS
TABELA 1 Comparação entre os codecs de vídeo mais utilizados.......................................50
TABELA 2 Comparação entre os codecs de áudio mais utilizados.......................................52
TABELA 3 Comparação entre os containers mais utilizados para streaming........................53
TABELA 4 – Versões de tecnologias livres utilizadas.............................................................65
TABELA 5 – Cenários utilizados nos testes...........................................................................102
TABELA 6 – Testes com forma analógica de captura...........................................................104
TABELA 7 – Testes com captura via RFB.............................................................................107
TABELA 8 – Testes com captura via Xlib.............................................................................108
TABELA 8 – Comparativo entre formas de captura de slides...............................................113
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
SUMÁRIO
1 INTRODUÇÃO....................................................................................................................15
2 MULTIMÍDIA......................................................................................................................18
2.1 Vídeo..................................................................................................................................18
2.1.1 Vídeo analógico..............................................................................................................18
2.1.2 Vídeo digital....................................................................................................................19
2.1.3 Espaço de conversão de cor............................................................................................21
2.2 Áudio..................................................................................................................................22
2.2.1 Áudio digital...................................................................................................................23
2.2.2 Canais de áudio...............................................................................................................24
2.3 Compressão de dados.........................................................................................................25
2.3.1 Compressão sem perda....................................................................................................25
2.3.2 Compressão com perda...................................................................................................26
2.3.3 Compressão e codificação de vídeo................................................................................27
2.3.4 Compressão e codificação de áudio................................................................................30
2.4 Containers de dados...........................................................................................................32
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
12
3 STREAMING.......................................................................................................................33
3.1 Redes de computadores......................................................................................................33
3.2 Streaming...........................................................................................................................35
3.2.1 Aplicações do streaming.................................................................................................36
3.2.2 A arquitetura do streaming..............................................................................................38
3.3 Os estágios de captura e codificação..................................................................................39
3.4 O estágio armazenamento e/ou distribuição......................................................................39
3.4.1 Streaming em temporeal................................................................................................42
3.4.2 Streaming sobdemanda..................................................................................................42
3.5 O estágio de visualização...................................................................................................43
3.6 Taxa de bits constante e variável.......................................................................................45
4 TECNOLOGIAS EXISTENTES..........................................................................................47
4.1 Padrões e codecs de vídeo..................................................................................................47
4.2 Padrões e codecs de áudio..................................................................................................50
4.3 Containers de dados...........................................................................................................52
4.4 Tecnologias livres..............................................................................................................53
4.4.1 O Formato Ogg...............................................................................................................53
4.4.2 O Codec Vorbis...............................................................................................................55
4.4.3 O Codec Theora..............................................................................................................56
4.4.4 O Framework Gstreamer.................................................................................................57
4.4.5 O Servidor Flumotion.....................................................................................................60
4.4.6 O applet Cortado.............................................................................................................63
4.4.7 O distribuidor Icecast......................................................................................................64
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
13
4.4.8 Versões utilizadas...........................................................................................................65
4.5 Ferramentas proprietárias para ensino à distância.............................................................66
4.5.1 Adobe Acrobat Connect Professional.............................................................................66
4.5.2 Microsoft Office Live Meeting.......................................................................................67
4.5.3 Wimba Classroom...........................................................................................................68
4.5.4 iLinc................................................................................................................................69
5 ESPECIFICAÇÃO DO AMBIENTE DE TRABALHO......................................................71
5.1 Recursos para a captura......................................................................................................72
5.1.1 Captura de vídeo.............................................................................................................73
5.1.2 Captura de áudio.............................................................................................................73
5.1.3 Captura de apresentação de slides...................................................................................73
5.1.3.1 Captura da saída de vídeo do computador...................................................................74
5.1.3.2 Captura do ambiente de trabalho compartilhado via RFB...........................................76
5.1.3.3 Captura do ambiente de trabalho compartilhado via chamadas ao modo gráfico do GNU/Linux...............................................................................................................................77
5.2 Recursos para a codificação...............................................................................................78
5.3 Recursos para a distribuição..............................................................................................78
5.4 Recursos para a visualização..............................................................................................79
6 DETALHAMENTO DA IMPLEMENTAÇÃO...................................................................81
6.1 O estágio de captura...........................................................................................................82
6.1.1 Captura da saída de vídeo do computador......................................................................82
6.1.2 Captura do ambiente de trabalho compartilhado via RFB..............................................84
6.1.3 Captura do ambiente de trabalho compartilhado via chamadas ao modo gráfico do GNU/Linux...............................................................................................................................86
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
14
6.2 O estágio de codificação....................................................................................................88
6.3 O estágio de distribuição....................................................................................................89
6.4 Os cenários completos desde a captura até a distribuição..................................................90
6.4.1 O cenário de captura da saída de vídeo do computador..................................................90
6.4.2 O cenário de captura da saída do ambiente compartilhado via RFB..............................94
6.4.3 O cenário de captura da saída do ambiente compartilhado via chamadas ao modo gráfico do GNU/Linux..............................................................................................................95
6.4.4 O cenário de distribuição utilizando o Icecast................................................................95
6.5 O estágio de visualização...................................................................................................96
7 ANÁLISE DA IMPLEMENTAÇÃO.................................................................................101
7.1 Captura e codificação.......................................................................................................101
7.1.1 Cenários utilizados nos testes.......................................................................................102
7.1.2 Testes com a captura da saída de vídeo do computador...............................................103
7.1.3 Testes com a captura via RFB.......................................................................................106
7.1.4 Testes com a captura via chamadas à Xlib....................................................................107
7.1.5 Análises comparativas...................................................................................................108
7.2 Distribuição......................................................................................................................113
7.3 Visualização.....................................................................................................................114
8 CONCLUSÃO....................................................................................................................115
REFERÊNCIAS......................................................................................................................118
APÊNDICES...........................................................................................................................121
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
1 INTRODUÇÃO
Os recursos multimídia, através do som e da imagem, estão cada vez mais presentes
em nossas vidas e têm contribuído consideravelmente para o aumento da quantidade de
conhecimento disponível, com uma qualidade cada vez maior. O livre acesso à informação é
uma realidade cada vez mais notada pela sociedade, principalmente devido à popularização da
Internet. A televisão, aos poucos, foi substituindo o rádio e o cinema e se tornou um
importante meio de comunicação em massa. A Internet, aos poucos, está tomando espaço da
televisão convencional, e a tendência é que isto se acentue com o tempo, principalmente
através da adaptação deste modelo de televisão para a televisão digital interativa.
O ensino à distância, utilizandose da multimídia, pode possibilitar o acesso a uma
parte da população que não tem condições de bancar os estudos, uma vez que este modelo de
ensino proporciona redução de custos principalmente em relação à infraestrutura física (DO
AMARAL, 2004).
O desenvolvimento de novas tecnologias de informação e comunicação tem sido
relevante para a criação de ambientes de aprendizagem que expandam as oportunidades de
combinação de recursos tecnológicos e humanos. O ensino à distância faz o uso destas novas
tecnologias para que o aluno não tenha limitações geográficas e que dependa de uma sala de
aula presencial para buscar sua qualificação (MEHLECKE , 2003).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
16
Seguindo esta linha, está se tornando comum a criação de ferramentas que simulam o
ambiente de sala de aula através da Internet. Grandes empresas, como a Adobe e a Microsoft,
têm explorado bastante esta área. Porém, atualmente, não existem tecnologias livres que
realizem esta tarefa.
Este contexto deu a motivação e estabeleceu principal objetivo deste trabalho, que é
apresentar uma solução que simula o ambiente de sala de aula nãointerativo através da
Internet, combinando recursos de áudio e vídeo com slides de uma apresentação, utilizandose
apenas tecnologias livres.
Além do objetivo acima definido, e de características inerentes a ele, como o baixo
custo devido ao fato do uso de tecnologias livres, outros objetivos podem ser ressaltados. O
primeiro deles é atingir taxas de bits baixas em relação à qualidade do vídeo, do áudio e dos
slides, permitindo que diversos clientes possam ser atendidos ao mesmo tempo. O segundo
objetivo é atender a vários cenários distintos de captura dos slides, uma vez que a solução
apresentada permite capturálos de três formas. O terceiro é fazer uma série de testes para
validar a solução apresentada. Por fim, temse também por objetivo avaliar e validar as
tecnologias livres empregadas, para verificar se estas estão suficientemente maduras para
utilização em ambientes de ensino à distância.
A solução apresentada contempla todos os estágios do streaming, que vão desde a
captura dos dados até a visualização do conteúdo por múltiplos clientes conectados através de
uma rede de computadores.
Com o trabalho aqui descrito, pretendese contribuir para o crescimento do ensino à
distância, especialmente no que diz respeito à utilização e à difusão de tecnologias livres.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
17
Os capítulos iniciais deste trabalho fornecem o embasamento teórico necessário para a
compreensão dos capítulos posteriores, sendo que o Capítulo 2 apresenta a teoria sobre
multimídia e o Capítulo 3 a teoria sobre streaming. Em seguida, no Capítulo 4, são
apresentadas as tecnologias existentes relacionadas a este trabalho, tanto livres quanto
proprietárias, bem como um maior detalhamento e uma justificativa da utilização das
tecnologias livres empregadas no desenvolvimento do trabalho. Na seqüência, no Capítulo 5,
é feita a especificação do ambiente de trabalho, onde são elencados os recursos necessários
para a utilização da solução. No Capítulo 6 é feito o detalhamento da implementação, onde
são apresentadas as adaptações necessárias a algumas tecnologias livres existentes e são dadas
diretivas de configuração destas. No Capítulo 7 é feita uma análise da implementação, onde
testes são apresentados juntamente com análises comparativas dos diversos cenários que
foram montados para validar a solução. Por fim, no Capítulo 8, é apresentada uma conclusão,
onde são comentados os resultados obtidos, são apresentadas as principais contribuições e são
citadas possíveis continuações para este trabalho.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
2 MULTIMÍDIA
Este capítulo apresenta uma visão geral sobre multimídia, especialmente sobre os
recursos de vídeo e áudio. Estas definições são fundamentais para dar embasamento à solução
desenvolvida por este trabalho.
2.1 Vídeo
A imagem em movimento, que também pode ser chamada de vídeo, é caracterizada
por uma série de imagens projetadas de forma rápida e sucessiva para dar a idéia de
movimento.
2.1.1 Vídeo analógico
Quando as câmeras de vídeo foram desenvolvidas, as imagens de entrada eram
capturadas, medidas e convertidas em uma série de valores elétricos. Estes valores, então,
puderam ser disponibilizados, recebidos e convertidos novamente em imagens. O vídeo foi
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
19
dividido em quadros e cada quadro dividido em unidades que pudessem ser medidas, que são
chamadas de linhas. Esta tecnologia é utilizada na televisão convencional até hoje.
O NTSC (National Television Standards Committee)1 decidiu por 30 quadros por
segundo como o padrão (baseado no valor de 60 Hz da corrente elétrica alternada), com cada
quadro dividido em 525 linhas horizontais.
Como a maioria dos países europeus tem a corrente elétrica em 50 Hz, houve a
necessidade de criação de padrões com 25 quadros por segundo. Assim surgiram o PAL
(Phase Alternation by Line)2 e o SECAM (Sequential Color and Memory)3, ambos com 625
linhas horizontais e 25 quadros por segundo.
2.1.2 Vídeo digital
A revolução dos produtos eletrônicos nos últimos 50 anos introduziu o conceito de
vídeo e áudio digital. Em vez de armazenar o áudio e o vídeo como valores elétricos ou ondas
magnéticas, o sinal é representado como uma série de números (bits) armazenados em
formato digital.
Os formatos digitais têm alguns benefícios em relação aos analógicos, principalmente
pelo fato de que as cópias entre este formato são idênticas, fato que não ocorre no sistema
analógico, onde cada cópia sofre degradação, e, conseqüentemente, perde qualidade. Os
formatos digitais também são mais fáceis de se editar e processar.
1 NTSC Sistema de televisão analógico usado principalmente nos Estados Unidos, Canadá e Japão.2 PAL Sistema de televisão analógico usado principalmente na Europa. O Brasil usa uma variante do PAL
chamada PALM.3 SECAM Sistema de televisão analógico usado principalmente na França e Rússia.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
20
Antes de iniciar o processo de edição e codificação do vídeo, é necessário que este seja
transferido para o computador num formato que ele possa manipular. Se a fonte geradora de
vídeo for analógica, é necessária a utilização de algum equipamento, como uma placa de
captura de vídeo, que transforme o sinal analógico em digital. Se a fonte geradora for digital,
os dados simplesmente são transferidos digitalmente entre a fonte geradora e o computador
através de canais de alta velocidade como FireWire1 ou USB 2.0.
A digitalização de vídeo consiste em dividir cada quadro em uma série de pixels. O
pixel é o menor ponto (ou menor elemento) de uma imagem com uma cor atribuída. A
medição do número de pixels horizontais pelo número de pixels verticais é denominada
resolução, e esta resolução define o tamanho de cada quadro. O problema é que digitalizar
vídeo em alta qualidade significa usar a maior resolução possível, e quanto mais alta for a
resolução, mais pixels existirão, o que significa armazenar mais dados.
Um dos desenvolvimentos mais importantes dos últimos anos foi o do padrão IEEE
1394. Muitos computadores e câmeras estão vindo com este padrão embutido numa porta
FireWire. Utilizando FireWire, o vídeo pode ser transferido digitalmente, direto da câmera
para o computador. Quando um vídeo analógico é digitalizado, ocorrem perdas de
informação, ou seja, degradação da qualidade. Quando o processo é inteiramente digital, os
dados são transferidos fielmente para o computador. Neste caso, a única perda que ocorre é
em relação à capacidade que o sensor da câmera digital tem de capturar o mundo real.
1 FireWire – Interface serial do padrão IEEE 1394 para computadores pessoais e aparelhos digitais de áudio e vídeo que oferece comunicação de alta velocidade. É o padrão digital de conexão para áudio e vídeo mais utilizado profissionalmente.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
21
2.1.3 Espaço de conversão de cor
O mecanismo biológico responsável pela visão humana tem dois tipos de sensores: os
bastões, que são sensíveis à intensidade da luz; e os cones, que são sensíveis aos níveis do
espectro visível, composto pelas cores vermelho, verde e azul, que dão origem ao formato
chamado de RGB1 (Red Green Blue). Para dar uma impressão realística das cores, o sistema
de televisão é baseado no espectro de visão das três cores primárias, justamente composto
pelas cores que formam o RGB.
Para representar o formato RGB digitalmente, tipicamente são necessários 24 bits para
cada pixel de uma imagem, sendo 8 para cada cor, especificando o nível de intensidade de
cada uma delas.
Uma das necessidades do padrão NTSC inicialmente era manter a compatibilidade
com o sistema monocromático. Para este fim, o espaço de cor RGB pode ser mapeado
(através de uma matriz de cor) em sinal de luminância (já utilizado pelo receptor
monocromático) e duas diferenças de cor ou sinais de crominância. O componente de
luminância é chamado de Y, e os componentes de cor são chamado de BlueY (ou U) e Red
Y (ou V). Este esquema de cores é chamado de YUV. Num processo reverso, o sinal original
RGB pode ser derivado pelo receptor a partir do YUV. Este processo é ilustrado na FIGURA
1.
1 RGB – Sistema de cor aditivo composto pelas cores primárias vermelho, verde e azul.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
22
FIGURA 1 Os padrões RGB e YUVFonte: Austerberry (2004)
O esquema de cores YUV pode utilizar as limitações da visão humana para mostrar a
mesma quantidade de informação perceptível em 24, 16, 12 ou 9 bits, com alguma degradação
de qualidade. Isso é feito reduzindo os valores de crominância, que trazem menos
informações perceptíveis ao sistema de visão humana que a luminância, e pode ser útil para
reduzir a largura de banda necessária e a capacidade de armazenamento.
2.2 Áudio
As tecnologias de armazenamento de áudio digital, como os discos compactos (CDs),
já estão difundidas há muito tempo, e, principalmente pela qualidade e custo acessível, já se
tornaram padrão de mercado.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
23
2.2.1 Áudio digital
Para digitalizar o áudio, é necessário converter as ondas elétricas do sinal analógico
em informação digital. Para fazer isto, são feitas medições da amplitude da onda em
diferentes pontos uniformemente espalhados no tempo e os valores resultantes são
armazenados seqüencialmente. A FIGURA 2 ilustra esta transformação.
FIGURA 2 Uma onda de som é digitalizada usando amostragem discretaFonte: Mack (2002)
Por natureza, o áudio digital envolve amostragem discreta. Cada caixa dentro da forma
de onda original na FIGURA 2 representa uma amostra. Quanto mais alta for a taxa de
amostragem, mais precisa será a forma de onda digitalizada. Isto ocorre devido à existência de
um mecanismo de filtragem analógico inerente ao mecanismo de audição humana.
Como pode ser visto na FIGURA 2, transformar um áudio analógico em digital resulta
na representação de degraus para simular a curva original. Conforme a taxa de amostragem
aumenta, o efeito de degraus fica menos perceptível, e o resultado digital se aproxima da
curva original.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
24
Outra medida importante no áudio digital é a largura de bits (ou bit length). Para cada
amostra coletada, é necessário associar um número ao valor elétrico. A largura de bits se
refere ao número de bits utilizados para armazenar esse valor numérico. Quanto mais bits
forem usados, maior será a precisão.
Os CDs, por exemplo, são amostrados numa taxa de 44.100 amostras por segundo
(44.1 kHz). Em relação à largura de bits, os CDs utilizam 16 bits de largura para cada
amostra. Isto é considerado suficiente para capturar o espectro audível completo.
2.2.2 Canais de áudio
O áudio pode ser transmitido como um canal simples, chamado de monofônico (ou
mono), ou pode ter uma informação de alcance espacial através da utilização de multicanais.
Quando um som tem dois canais, ele é chamado de estéreo, e esse é o padrão mais popular
para a reprodução de áudio digital.
O cinema e os home theaters introduziram o áudio surround, que simula um som
envolvente, como se o ouvinte estivesse dentro do som. O surround geralmente está no
formato 5.1, que se refere a cinco canais mais um canal de efeitos de baixa freqüência
(graves).
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
25
2.3 Compressão de dados
A compressão de dados reduz o número de bits utilizados para representar uma
informação. As técnicas utilizadas para comprimir vídeo e áudio são diferentes, ou seja, deve
se procurar uma técnica de compressão adequada para cada situação.
Os algoritmos de compressão de dados são classificados de duas maneiras: sem perda,
onde o arquivo original pode ser recriado exatamente a partir de um arquivo comprimido e
com perda, onde o arquivo descomprimido é uma aproximação do arquivo original o quanto
aproximado é em relação ao original depende da quantidade de compressão utilizada.
2.3.1 Compressão sem perda
A compressão sem perda tira vantagem da informação redundante. Esta redundância
pode ser representada de uma maneira mais eficiente. Por exemplo, a seqüência
AAAAAAAA pode ser armazenada como 8A. Esta técnica é conhecida como compressão
RLE (RunLength Encoding). Neste exemplo, em vez de armazenar oito caracteres, é
necessário armazenar apenas dois. Neste caso simples, a necessidade de armazenamento é
reduzida em 75%.
Outra técnica de compressão sem perda é conhecida como entropia. Entre estas
técnicas, está a codificação de Huffman, nomeada pelo seu criador, David Huffman. Esta
técnica se baseia na distribuição de valores para garantir maior eficiência, ou seja, valores
repetidos, muitas vezes, têm menor representação de bits.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
26
Os algoritmos de compressão de arquivos utilizam técnicas de compressão sem perdas.
Os arquivos originais podem ser recriados exatamente como estavam antes de serem
comprimidos.
A compressão de dados sem perda é útil para manter a qualidade, porém a proporção
de compressão costuma ser moderada.
2.3.2 Compressão com perda
A compressão com perda é caracteriza por altas proporções de compressão através do
descarte de informações que são consideradas redundantes ou desnecessárias. Pelo fato de
algumas informações serem descartadas, a recriação da informação original se torna
impossível.
Algumas vezes os algoritmos de compressão com perda precisam ser severos. Em
casos de extrema compressão, estes algoritmos fazem o melhor para reter a qualidade original,
mas podem ser forçados a descartar uma grande quantidade de informação. O objetivo em
casos como este é tentar manter a informação mais importante e descartar o resto, fazendo
com que a perda se torne menos perceptível.
Inevitavelmente, com o aumento da complexidade dos algoritmos de compressão com
perda, aumenta também a quantidade de recursos de processamento necessários para
comprimir os dados.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
27
2.3.3 Compressão e codificação de vídeo
Um vídeo digitalizado bruto, ou seja, sem nenhuma compressão, com uma resolução
de 640x480 pixels, com 30 quadros por segundo, pode ter seu tamanho obtido através do
seguinte cálculo:
● 640 * 480 * 30 = 9.216.000 pixels
● 9.216.000 * 24 bits (RGB) = 221.184.000 bits
● 221.184.000 / 8 = 27.648.000 bytes
● 27.648.000 / 1024 / 1024 = 26,4 MB
Em apenas um segundo de um vídeo bruto em formato VGA, temse 26,4 MB de
informação, o que torna praticamente inviável o seu armazenamento em termos de volume de
dados, pois uma hora de vídeo ultrapassa 92 GB de informação. Inevitavelmente é necessário
encontrar uma forma de reduzir este volume de dados. Caso a resolução do vídeo seja maior,
como um vídeo de alta definição (1920x1080), este problema é ainda mais crítico.
As formas mais imediatas para reduzir os dados são o tamanho da tela e a relação de
quadros. A redução desses dois fatores não caracteriza uma compressão de dados, e sim um
descarte de informação ajustado de acordo com a necessidade da aplicação.
Num exemplo simples, se for multiplicado um quadro de 640x480, teremos mais de
trezentos mil pixels de informação. Se o quadro for dividido pela metade, ou seja, 320x240,
teremos apenas um quarto dos pixels em relação ao quadro anterior. Essa é uma definição
importante para se definir um meio termo entre o tamanho do quadro e a qualidade do vídeo.
Outra forma de economia é reduzir a relação de quadros por segundo. Qualquer valor
acima de vinte quadros por segundo é adequado para que o olho humano tenha a idéia de
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
28
movimento. Porém, para conteúdos que têm pouco movimento, é seguro reduzir o número de
quadros obtendo uma percepção de movimento aceitável. Só para se ter uma idéia, se aquela
resolução inicial de 640x480, com trinta quadros por segundo, for reduzida para 160x120,
com dez quadros por segundo, teremos apenas 3,125% de informação em relação ao início.
Após este redução de informação, caso ela seja necessária, iniciase o processo de
compressão propriamente dito. Os sistemas de compressão de imagem exploram o mecanismo
de percepção visual para remover informações redundantes, mas produzem uma experiência
visual convincente.
Existem diversas técnicas que os algoritmos de compressão de vídeo utilizam para
economizar informação. Entre elas está a compressão interframe, que também é conhecida
por compressão temporal. Esta técnica conta com o fato de que boa parte (ou todo) do
conteúdo do vídeo pode permanecer inalterado entre os quadros, ou seja, que haja uma
redundância entre as imagens. Desta forma, é armazenada apenas a diferença entre os
quadros, e o que permaneceu inalterado é descartado. Como existe erro associado à
localização das redundâncias, os algoritmos que utilizam essa técnica precisam inicialmente
comprimir um quadro completo para estabelecer os elementos presentes na imagem para
então calcular as diferenças entre os quadros. O quadro estabelecido é chamado de quadro de
referência e os outros são chamados de quadros de diferença. Em vídeos onde há pouco
movimento, essa economia pode ser significativa, pois não será necessário utilizar muitos
quadros de referência.
Outra técnica importante é a compressão intraframe. Esta técnica se baseia na
compressão de cada quadro separadamente, ao contrário da interframe, que utiliza a relação
entre quadros. Como exemplos de mecanismos que utilizam essa técnica podese citar o PNG
e o JPEG.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
29
Além das técnicas citadas, existem outras que exploram as redundâncias existentes em
um sinal de vídeo. Basicamente a redundância pode ser classificada em espacial, temporal, de
percepção e estatística. A redundância espacial é explorada através de técnicas como a
compressão intraframe. A temporal é explorada por compressões como a interframe. A
redundância de percepção explora o sistema de visão humano, que não trata todos os tipos de
informação visual com a mesma relevância, como, por exemplo, a baixa habilidade de
perceber detalhes de cor se comparados com luminosidade. Por último, vem a compressão
estatística, que busca repetições (já visto na compressão sem perda) no sinal de vídeo para
economizar informação.
Todas estas técnicas podem ser combinadas para que se obtenha um resultado final
mais satisfatório.
Os programas que realizam esta compressão são chamados de codec. Eles utilizam
uma série de algoritmos matemáticos que transformam dados de um formato para outro. Seu
nome é dado através de uma abreviação de codificação/decodificação.
Os codecs são utilizados para reduzir o tamanho das informações de vídeo e áudio
originais (brutos). Posteriormente, eles são utilizados para converter os dados comprimidos de
volta ao formato original para que possam ser visualizados pelo cliente. Para que isto seja
possível, o mesmo codec que foi utilizado para comprimir os dados deve ser utilizado para os
descomprimir.
Os codecs costumam combinar diversas técnicas de compressão de dados para
conseguir um maior desempenho na compactação, e podem ser caracterizados como
simétricos ou assimétricos. Um codec simétrico necessita de menos processamento no
servidor, porém, a quantidade de processamento utilizada na codificação e na decodificação
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
30
são semelhantes. Já os codecs assimétricos utilizam técnicas de compressão que exigem mais
tarefas que as de descompressão. Isto significa que o processo de codificação necessita de
mais processamento que a decodificação.
2.3.4 Compressão e codificação de áudio
Um áudio digitalizado bruto com uma taxa de amostragem de 44.1kHz, com uma
largura de 16 bits, com dois canais, pode ter seu tamanho obtido através do seguinte cálculo:
● 44.100 * 16 * 2 = 1.411.200 bits
● 1.411.200 / 8 = 176.400 bytes
● 176.400 / 1024 = 172,27 KB
● 172,27 * 60 / 1024 = 10MB
Em um minuto de um áudio bruto em formato PCM, teremos aproximadamente 10MB
de informação. Neste caso, o problema de armazenamento não é tão crítico quanto do vídeo,
mas uma transmissão através da Internet utilizando estes dados se torna inviável.
Uma técnica simples para diminuir a quantidade de informação relativa ao áudio é
diminuir o número de canais. Por exemplo, se um sinal estéreo for convertido num sinal
monofônico, a quantidade de informação necessária para representar o áudio será reduzida
pela metade.
Outro fator determinante para a diminuição dos dados é taxa de amostras. Este valor
pode ser restringido de acordo com o tipo de conteúdo que está sendo comprimido. Por
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
31
exemplo, para voz humana, 8kHz é suficiente, mas para sons de alta definição é necessário
utilizar freqüências maiores que 44kHz, como é utilizado no CD.
Após esta redução de informação, iniciase o processo de compressão propriamente
dito. Na compressão de áudio, o objetivo é manter a taxa e a dinâmica da freqüência original.
Se a taxa de bits por segundo for alta, isso é facilmente atingido. Porém, conforme a taxa de
bits for diminuindo, esse objetivo fica difícil de ser atingido, e tornase necessário abrir mão
de alguns dados. As técnicas de compressão baseadas na percepção auxiliam na manutenção
da fidelidade tomando decisões sobre o que pode seguramente ser descartado e para que parte
do áudio é necessário destinar mais bits.
Muitas características da audição humana também são exploradas pelas técnicas de
compressão baseadas na percepção. O estudo desta audição é chamado de psicoacústica. Entre
os fatores que são explorados por esta técnica estão a faixa de freqüência que o ouvido
humano pode detectar, com a definição do ponto mínimo da audição, onde freqüências acima
e abaixo dessa faixa podem ser descartadas, o mascaramento, onde sons muito altos fazem
outros de volume mais baixo se tornem inaudíveis, tornando possível que esses possam ser
descartados, e também a curva de resposta da audição humana, que não é linear.
Os codecs utilizados para vídeo e áudio são diferentes, pois as técnicas de compressão
também são diferentes.
No caso dos codecs de áudio, existe um detalhe que torna a codificação mais
complexa. As técnicas que os codecs utilizam para comprimir música e voz são diferentes.
Em virtude disto, existem codecs de áudio específicos para voz e outros para propósito geral.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
32
2.4 Containers de dados
Depois de o áudio e o vídeo serem codificados, eles precisam ser colocados
encapsulados.
Este encapsulamento, que podem conter vários tipos de dados, geralmente áudio e/ou
vídeo comprimidos por um codec, são chamados de containers.
Os containers empacotam o áudio e o vídeo usando marcações ou índices. Isto permite
que diversos áudios e/ou diversos vídeos possam estar dentro de um único arquivo, tornando
possível, por exemplo, que um vídeo possa ser transmitido em múltiplas línguas. Os
containers mais modernos possibilitam também que o arquivo contenha outros tipos de
conteúdo, como legendas e imagens.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
3 STREAMING
Neste capítulo são apresentados os conceitos de redes de computadores e de
streaming. Estes assuntos também são fundamentais para dar embasamento à solução
proposta por este trabalho.
3.1 Redes de computadores
Devido ao rápido progresso tecnológico, principalmente no campo da informação,
todas as áreas da tecnologia estão convergindo rapidamente. À medida que cresce nossa
capacidade de colher, processar e distribuir informações, tornase ainda maior a necessidade
de formas de processamento de informações cada vez mais sofisticadas (Austerberry, 2004).
Para atender essas necessidades, surgiram as “redes de computadores”, que tornaram
possível a troca de informações entre uma série de computadores interconectados.
Com o passar dos anos, surgiu a necessidade de que as redes de computadores, além
de interligarem computadores próximos, também pudessem interligar computadores ou redes
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
34
mais distantes. A partir dessa necessidade, com a conglomeração de diversas redes de
computadores, surgiu a Internet.
Através da Internet, é possível que pessoas e empresas de todo o mundo estejam
interligadas e possam trocar informações e compartilhar recursos. Esta interligação
possibilita, entre outras coisas, o acesso a informações remotas, a comunicação entre pessoas,
a diversão interativa, podendo até, em alguns casos, substituir a presença física.
As redes de computadores possibilitam a utilização de computadores centralizadores
de serviços, que são chamados de servidores. Esses computadores centralizam serviços para
uma rede local, como compartilhamento de arquivos e autenticação ou até mesmo para a
Internet, como um servidor de páginas de conteúdo ou um servidor de correio eletrônico. Os
usuários que utilizam esses serviços, através de seus computadores pessoais, são os clientes.
No modelo cliente/servidor, a comunicação costuma se dar através de uma mensagem
de solicitação do cliente enviada ao servidor, pedindo para que alguma tarefa seja executada
ou alguma informação seja disponibilizada. Em seguida, o servidor atende à requisição e
envia a resposta. Geralmente, há muitos clientes usando um pequeno número de servidores
(Tanenbaum, 1997). Este modelo é ilustrado na FIGURA 3.
FIGURA 3 – O modelo cliente/servidorFonte: Tanenbaum (1997)
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
35
Para a comunicação entre cliente e servidor, a definição de largura de banda é um
característica fundamental. A largura de banda se refere à taxa de dados que são enviados
num intervalo de tempo, sendo calculada através do número de bytes transmitidos por
segundo em uma direção durante um determinado intervalo de tempo .
3.2 Streaming
O áudio e o vídeo são meios mais naturais de comunicação do que o texto e a imagem,
já usados por décadas na Internet. A multimídia está e estará cada vez mais presente na
Internet, principalmente através das páginas Web. A tendência é que as páginas estáticas, aos
poucos, sejam substituídas por páginas dinâmicas com cada vez mais recursos multimídia.
Uma boa alternativa para contribuir com isso é o streaming, que é a tecnologia que
possibilita o envio de informações multimídia (geralmente vídeo e áudio) através de uma rede
de computadores.
O streaming é caracterizado pelo fato de o cliente receber o conteúdo multimídia
como um um fluxo de informação contínuo. Também é caracterizado por não ser necessário
que todos os dados cheguem no cliente, pois a apresentação pode começar assim que
chegarem os primeiros dados. Depois que o cliente visualiza o conteúdo do streaming, os
dados são descartados. Esta característica de descarte de dados é inédita do streaming.
Na televisão convencional, o aparelho doméstico apenas recebe o sinal, o que
caracteriza uma conexão de apenas uma direção. No streaming, uma conexão bidirecional é
mantida enquanto o espectador estiver recebendo informação, o que possibilita adicionar
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
36
recursos de interatividade ou até mesmo saber quantos espectadores estão conectados em
determinado momento.
Conforme os equipamentos relacionados à multimídia foram evoluindo, a qualidade e
a fidelidade das imagens também foram aumentando, e essa é uma relação que deve se manter
com o surgimento de novas tecnologias. Ironicamente, o streaming inverteu essa tendência.
Enquanto clientes e produtores de conteúdo necessitam da melhor qualidade possível, as
limitações das larguras de banda impuseram severas restrições na taxa de bits por segundo do
streaming, o que afeta sua qualidade. O “cabodeguerra” entre qualidade e largura de banda é
o que direciona o desenvolvimento do streaming atualmente. Conforme a tecnologia melhora
e a largura de banda aumenta, essa relação tende a mudar, e, portanto, pode ser vista como um
empecilho temporário. Novas tecnologias estão começando a auxiliar na inversão desta
relação.
3.2.1 Aplicações do streaming
Potencialmente, o streaming pode ser utilizado em ensino à distância (aulas, palestras,
treinamentos), entretenimento, publicidade e comunicação corporativa (relações humanas,
monitoramento, relacionamento com imprensa).
O ensino à distância deve crescer exponencialmente com a consolidação do streaming
como uma alternativa de disponibilização de informação. Ainda hoje, boa parte do ensino à
distância é baseado em correio eletrônico e conteúdos estáticos. Com streaming, é possível
que a informação seja disponibiliza de uma forma mais eficaz, ou seja, em tempo real com
recursos de interatividade.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
37
A FIGURA 4 ilustra algumas aplicações do streaming, neste caso como uma
alternativa para o CDROM e para o DVD, e principalmente para o videocassete e para o
conteúdo disponibilizado via satélite, nesses últimos casos substituindo a televisão
convencional.
FIGURA 4 – O streaming como uma alternativa para transmissão multimídiaFonte: Austerberry (2004)
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
38
3.2.2 A arquitetura do streaming
Basicamente, existem quatro estágios que definem a arquitetura de um streaming,
desde sua captura até sua visualização. A FIGURA 5 ilustra esta arquitetura.
FIGURA 5 Os quatro estágios do streamingFonte: Austerberry (2004)
O estágio de captura capta o áudio e o vídeo do microfone e da câmera. O estágio de
codificação processa o áudio e o vídeo e os encapsula em um arquivo. Posteriormente, este
arquivo é enviado para um servidor de conteúdo, que pode transmitilo em tempo real ou
armazenálo para transmissão em outro momento. O último estágio, o de visualização, recebe
o streaming e é responsável por descompactar o arquivo e reproduzir o vídeo e o áudio no
cliente.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
39
3.3 Os estágios de captura e codificação
Antes do áudio e do vídeo serem transmitidos via streaming, eles precisam passar por
uma série de estágios de processamento.
Os estágios de captura e codificação de vídeo começam com alguma fonte geradora de
imagem ou de som, como uma câmera, por exemplo. O segundo passo é capturar o vídeo ou o
áudio e transformálos em vídeo bruto ou em áudio bruto, ou seja, nem nenhuma
compactação, processo que é chamado de captura de vídeo ou digitalização. Finalmente, ele
deve ser processado pelo codec, que comprime os dados conforme for indicado pelo
administrador do sistema para atender a largura de banda desejada.
3.4 O estágio armazenamento e/ou distribuição
O segundo estágio do streaming é o de armazenamento e/ou distribuição. Depois de
criado o arquivo com os dados de vídeo e áudio, esse arquivo deve ser enviado a um servidor
para distribuição através de uma rede de computadores ou armazenado para posteriormente
ser distribuído sob demanda. O processo que permite a disponibilização do conteúdo através
da rede é o streaming propriamente dito. O computador que executa esse processo pode ser o
mesmo que executa o processo de captura e codificação.
Um servidor de streaming é mais do que apenas um simples servidor de arquivos, pois
ele controla a entrega do fluxo de informação em temporeal. Para disponibilizar o streaming,
é necessária uma conexão persistente entre o cliente e o servidor e um fluxo contínuo de
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
40
dados. Se algum problema ocorrer, o serviço pode ser comprometido, o que pode resultar em
um vídeo distorcido ou trancado ou em um áudio mudo ou com ruídos.
O problema é que a Internet não foi originalmente projetada para suportar fluxos
contínuos através de conexões persistentes. Uma série de desenvolvimentos estão ajudando a
melhorar a qualidade de entrega. Um deles é o aumento da largura de banda das conexões
com a Internet. Novos padrões estão se difundindo e as chamadas conexões de banda larga
(conexões mais rápidas que as discadas) se popularizando.
Um ponto importante da distribuição é a capacidade de atendimento de clientes. Este
detalhe é muito importante para definir a taxa de bits do streaming na hora da codificação. Por
exemplo, se o servidor tiver uma largura de banda de saída de 1Mbit/s, e o streaming estiver
sendo codificado numa taxa de bits de 100kbps, no máximo dez clientes poderão ser
atendidos simultaneamente. Se o streaming for codificado em 50kbps, vinte clientes poderão
ser atendidos simultaneamente. Esta é uma decisão importante a ser tomada na hora de montar
um serviço de streaming, sempre encontrando uma melhor relação custo x benefício.
A FIGURA 6 ilustra um streaming desde a captura até a sua visualização.
Primeiramente o áudio e o vídeo são digitalizados e comprimidos. Depois eles são unidos
num container de dados. Posteriormente esse container é empacotado para que possa ser
enviado através de uma rede de computadores. O passo seguinte é o tráfego dos pacotes de
sua origem até seu destino através de uma rede IP (Internet Protocol). Já no cliente, container
é desempacotado. Por último, o áudio e o vídeo são separados e descomprimidos para então
serem reproduzidos.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
41
FIGURA 6 O streaming desde a captura até a visualizaçãoFonte: Austerberry (2004)
Um streaming pode ser caracterizado como sendo em temporeal ou sobdemanda.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
42
3.4.1 Streaming em temporeal
Um streaming pode ser considerado em temporeal quando a informação está sendo
transmitida direto da fonte de captura para o espectador, ou seja, sem passar por um processo
intermediário de gravação. Um sinônimo para streaming em temporeal é streaming ao vivo.
O processo é similar à televisão convencional, onde o conteúdo é capturado e distribuído
através de uma rede até o receptor doméstico. Nesta categoria do streaming, todos os
espectadores assistem ao mesmo conteúdo ao mesmo tempo. Uma ilustração dessa categoria é
mostrada na FIGURA 7.
3.4.2 Streaming sobdemanda
O streaming pode ser considerado sobdemanda quando o conteúdo disponibilizado ao
espectador está previamente gravado. Nesta categoria, o conteúdo é disponibilizado ao cliente
do ponto que ele escolher. É possível que a qualquer momento o espectador possa assistir a
um vídeo, e, também a qualquer momento, pausálo. Este é o processo utilizado por grandes
sites concentradores de arquivos multimídia. Este processo difere um pouco do download
FIGURA 7 Streaming em temporealFonte: Austerberry (2004)
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
43
tradicional, pois o conteúdo não precisa ser inteiramente baixado para ser assistido. Uma
ilustração dessa categoria é mostrada na FIGURA 8.
3.5 O estágio de visualização
O último estágio do streaming é a visualização. Este processo é executado pelo
reprodutor multimídia, que é equivalente ao receptor de televisão.
Para que o reprodutor multimídia interprete os dados, é necessário que o mesmo codec
que foi utilizado para codificar os dados seja utilizado para os decodificar.
FIGURA 8 Streaming sobdemandaFonte: Austerberry (2004)
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
44
Um reprodutor multimídia pode ser um software independente, instalado no sistema
operacional ou um plugin1 em um navegador Web. Neste último caso, o streaming é tratado
como parte de uma mídia rica (que pode ser composta por texto, imagem, som e vídeo), ou de
uma página Web dinâmica.
Atualmente este processo não se restringe a computadores normais. Já é possível que
os streamings sejam disponibilizados para a televisão digital e para redes sem fio, onde
celulares 3G e computadores de mão (PDAs) podem interpretar os dados. A FIGURA 9
ilustra esta relação.
FIGURA 9 Reprodução de multimídia via streaming Fonte: Austerberry (2004)
1 Plugin – Extensão que fornece recursos adicionais a um programa de computador, geralmente desenvolvido por terceiros.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
45
3.6 Taxa de bits constante e variável
Como a compressão de vídeo e de áudio se baseia, entre outras coisas, em redundância
na informação, quanto ela ocorre bastante, a qualidade fica melhor, pois não é necessário
descartar muita informação para atingir a taxa de bits especificada. Porém, quando há pouca
redundância, é necessário descartar muita informação para atingir a taxa de bits especificada,
o que acaba fazendo com que a qualidade piore.
A maioria dos codecs de streaming, por padrão, codificam em taxa de bits constante
(CBR – Constant Bit Rate). Isto significa que sempre, em um determinado intervalo de
tempo, teremos a mesma quantidade de dados. Por exemplo, em um streaming de 56kbps,
teremos sempre 56.000 bits por segundo. Quando a largura de banda disponível para distribuir
o streaming for limitada, isto é uma vantagem, pois é possível saber exatamente quantos
clientes poderão ser atendidos pelo serviço de streaming, supondo que a rede esteja sempre
disponível.
Além da codificação em taxa de bits constante, existe também a codificação em taxa
de bits variável (VBR – Variable Bit Rate). O vídeo MPEG2, por exemplo, que é utilizado
no DVD, tem uma taxa de bits variável, dependendo da entropia do conteúdo original. Para
evitar a queda de qualidade, a taxa de bits do DVD aumenta quando há muito movimento na
cena, passando do valor típico de 3Mbit/s para até 8Mbit/s. O resultado final é uma qualidade
constante para quem está visualizando o vídeo. Na codificação do DVD, para otimizar a
codificação com um tamanho de arquivo específico (capacidade do DVD) é necessário usar a
técnica de duas passadas. A primeira apenas analisa o conteúdo e a segunda codifica
utilizando os parâmetros da primeira.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
46
A técnica de taxa de bits variável tem sido utilizada por alguns codecs de streaming,
conseguindo melhorar a qualidade quando comparado com os mecanismo CBR. Os codecs
utilizam o servidor e o buffer do cliente para usar uma taxa de bits média, simulando assim
uma taxa de bits constante, o que para a rede de computadores fica imperceptível, ou seja,
semelhante a uma taxa de bits fixa.
A FIGURA 10 ilustra dois streamings, sendo um constante e outro variável. Podese
perceber que, durante as cenas de ação, a qualidade do streaming VBR é melhor que a do
CBR.
FIGURA 10 – Taxa de bits varíavel e constanteFonte: Austerberry (2004)
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
4 TECNOLOGIAS EXISTENTES
Neste capítulo são listadas as tecnologias existentes de codificação de vídeo, de
codificação de áudio e de containers de dados, tanto proprietárias quanto livres. Na seqüência
é apresentada uma visão mais aprofundada das tecnologias livres utilizadas para desenvolver
a solução que este trabalho propõe, juntamente com a justificativa de escolha de cada uma
delas. Por fim, são apresentadas as soluções proprietárias existentes para utilização em ensino
à distância, que tem objetivo semelhante ao da solução livre apresentada por este trabalho.
4.1 Padrões e codecs de vídeo
Existem diversos codecs de vídeo, entre proprietários, abertos e livres. Entre eles,
muitos podem ser utilizados para streaming. Os principais padrões e codecs relacionados a
esta tecnologia são listados a seguir.
● O H.261, criado em 1990, e o H.263, criado em 1995, são dois padrões de
vídeoconferência que foram desenvolvidos pela ITU (International
Telecommunications Union) quando começou a ficar muito óbvio que as
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
48
telecomunicações e as indústrias de computadores estavam andando cada vez mais
lado a lado. Estes dois padrões formam a base de diversos outros codecs.
● A entidade MPEG (Moving Picture Experts Group) foi formada no final dos
anos 80 para desenvolver um sistema para codificar os vídeos a serem usados pelas
aplicações do CDROM. O MPEG1 foi criado em 1992 e foi inicialmente projetado
para trabalhar com uma taxa de bits de 1.5Mbit/s (velocidade máxima de leitura do
CDROM na época) e fornecer qualidade semelhante ao VHS. O MPEG2, criado em
1995, é uma evolução do MPEG1, possibilitando a utilização de tamanhos de
imagens e taxas de bits maiores, entre outros recursos. O padrão MPEG2, até hoje, é
muito difundido no mercado, e é a codificação de vídeo utilizada nos DVDs.
● O MPEG4 engloba novos mecanismos de codificação de vídeo e áudio, assim
como novas tecnologias de compressão de vídeo que tratam diferentes elementos no
vídeo como objetos separados. Isto permite, por exemplo, que personagens e fundo de
cena sejam tratados isoladamente com recursos de taxa de bits e qualidades diferentes.
Entre as implementações de codecs de vídeo mais difundidas do MPEG4 estão o
DivX e o Xvid. O DivX é um codec de vídeo proprietário,. O Xvid é um codec de
vídeo aberto e livre de patentes. Os dois disputam o posto de codec mais utilizado do
padrão MPEG4.
● O H.264 é um padrão para compressão de vídeo, também conhecido como
MPEG4 parte 10 ou AVC (Advanced Video Coding). A intenção do projeto H.
264/AVC foi criar um padrão capaz de fornecer boa qualidade de vídeo com uma taxa
de bits muito baixa em relação aos padrões já existentes, como o MPEG2 e o H.263,
que gerou um aumento significativo na complexidade computacional do codificador.
Outra meta do projeto foi fazer um padrão que fosse compatível com todas as
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
49
necessidades, isto é, compatível com vídeos de baixa e alta taxa de bits ou com baixa e
alta resolução. O H.264 é o padrão de codificação de vídeo mais promissor do
mercado e vem sendo amplamente adotado. Exemplos desta adoção são as
especificações dos padrões de televisão digital e a compatibilidade com o Flash, da
Macromedia, o que está fazendo com que portais concentradores de vídeos, como o
YouTube, migrem para este formato. Um exemplo da implementação deste padrão é o
x264.
● O padrão Ogg é um formato aberto e livre de patentes, mantido pela fundação
Xiph.Org1. O principal codec de vídeo que utiliza esse padrão é o Theora. Outro codec
desse formato é o Tarkin, que ainda está em fase de desenvolvimento, e, portanto,
pouco difundido.
● A Tecnologia Windows Media da Microsoft tem uma família de codecs com
uma série de recursos internos de tecnologias de terceiros. Os principais codecs de
vídeo desse padrão são o Windows Media Video 9 e o Microsoft MPEG4 V3.
● As tecnologias QuickTime, da Apple, já são utilizadas na criação multimídia
há muitos anos, e, de fato, o formato de arquivo do QuickTime foi usado como base
para o formato de arquivo do padrão MPEG4. Um dos principais codecs de vídeo do
Quicktime é o Sorenson.
A TABELA 1 apresenta uma comparação entre os principais codecs de vídeo com
perda existentes no mercado em relação à especificação de padrão (se é aberto ou fechado) e
em relação à dependência de patentes.
1 Xiph.Org Fundação sem fins lucrativos dedicada a proteger as fundações de multimídia via Internet do controle da iniciativa privada.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
50
TABELA 1 Comparação entre os codecs de vídeo mais utilizadosCodec Aberto Livre de patentes
Windows Media Video não não
Sorenson não não
DivX (MPEG4) sim não
x264 sim não
Xvid (MPEG4) sim não
MPEG1/MPEG2 sim não
Theora sim sim
Tarkin sim sim
4.2 Padrões e codecs de áudio
Assim como no vídeo, existem diversos codecs de áudio proprietários, abertos e livres.
Muitos deles podem ser utilizados por um streaming. Os principais padrões e codecs
relacionados a essa tecnologia são listados a seguir.
● Desde sua versão inicial, o MPEG já definia um padrão de codificação para
áudio e para vídeo. Do padrão MPEG1, surgiu o codec MP3, que é uma abreviação
de MPEG1 Layer 3, ou seja, utiliza a terceira camada do algoritmo MPEG de áudio.
O MP3 é o codec de áudio mais difundido, amplamente usado na Internet e em
aparelhos eletrônicos. Apesar de já ser bem antigo e de ser menos eficiente que boa
parte dos codecs de áudio existentes atualmente, o MP3 ainda é padrão de mercado.
Outro codec da família MPEG muito importante é o AAC (Advanced Audio Coding).
Ele é compatível com os padrões MPEG2 e MPEG4 e foi criado para ser o sucessor
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
51
do MP3. O AAC possui uma qualidade bem superior à do MP3 para a mesma taxa de
compressão.
● Dois codecs do padrão Ogg também muito importantes são o Vorbis e o Speex.
O Vorbis é um codec de áudio de propósito geral, enquanto o Speex é um codec
especializado em compressão de voz humana.
● Outro codec importante e muito utilizado pelo fato de utilizar compressão sem
perda é o FLAC (Free Losless Audio Codec). Esse codec tem um formato de arquivo
próprio, mas pode ser disponibilizado também no formato Ogg.
● Dos formato desenvolvidos pela Microsoft, os codecs de áudio mais
importantes são o Windows Media Audio 9 para música e o ACELP.net para voz.
● Do formato da Apple, os codecs de áudio mais utilizados são o Qdesign para
música e o QualComm PureVoice (QCELP) para voz.
A TABELA 2 apresenta uma comparação entre os principais codecs de áudio
existentes no mercado em relação à especificação de padrão (se é aberto ou fechado), em
relação à dependência de patentes, ao tipo de compressão de dados e finalidade.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
52
TABELA 2 Comparação entre os codecs de áudio mais utilizadosCodec Aberto Livre de patentes Tipo de compressão Utilização
Windows Media Audio
não não com perda geral
ACELP.net não não com perda voz
Qdesign não não com perda geral
QCELP não não com perda voz
MP3 sim não com perda geral
AAC sim não com perda geral
Vorbis sim sim com perda geral
Speex sim sim com perda voz
FLAC sim sim sem perda geral
4.3 Containers de dados
Existem diversos containers que podem ser utilizados para streaming. A maioria deles
já foi citado acima na definição dos padrões dos codecs.
Os principais e suas respectivas extensões de arquivo são os seguintes:
● MPEG4, .mp4;
● MPEG2, .mpeg ou .mpg;
● Formato de sistemas avançado da Microsoft, .asf;
● Quicktime, .mov;
● Ogg, .ogg.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
53
A TABELA 3 apresenta uma comparação entre os principais containers existentes no
mercado que suportam streaming em relação à especificação de padrão (se é aberto ou
fechado), em relação à dependência de patentes e aos principais codecs suportados.
TABELA 3 Comparação entre os containers mais utilizados para streamingContainer aberto livre de patentes principais codecs suportados
ASF não não Windows Media Audio (WMA), Windows Media Video (WMV)
QuickTime não não MP3, WMA,Vorbis, AAC, FLAC, MPEG1, MPEG2, Xvid, DivX,
WMV, Theora
MPEG4 sim não MP3, AAC, MPEG1, MPEG2, Xvid, DivX
Ogg sim sim Vorbis, Speex, FLAC, Theora, Tarkin
4.4 Tecnologias livres
Para o desenvolvimento do trabalho, foram utilizadas diversas tecnologias livres, que
serão aprofundadas a seguir.
4.4.1 O Formato Ogg
O Ogg é um padrão aberto de um formato de container, livre de patentes de softwares
e projetado para streaming e manipulação de conteúdo multimídia. O Ogg é mantido pela
fundação Xiph.Org.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
54
O container Ogg pode multiplexar diversos codecs para áudio, vídeo, texto e
metadados. Entre os codecs mais utilizados e difundidos compatíveis com este formato estão
o Vorbis e o Theora, mas o Ogg também suporta outros codecs, como o MP3 e os do padrão
MPEG4.
O formato de bitstream (fluxo de bits) do Ogg foi criado como sendo um framework
para o desenvolvimento de uma série de componentes para a codificação e decodificação de
conteúdo multimídia livres. Esse formato foi definido pela RFC 3533 (Pfeiffer, 2003) e seu
conteúdo pela RFC 3534 (WALLEIF, 2003).
O formato consiste em blocos de dados que são chamados de “página Ogg.” Cada
página começa com a string “OggS” para identificar o arquivo como um formato Ogg.
Um “número de série” e “número de página” no cabeçalho da página Ogg identificam
cada página como um pedaço da seqüência de páginas que formam o bitstream. Múltiplos
bitstreams podem ser multiplexados no arquivo onde páginas de cada bitstream são ordenadas
pelo tempo do conteúdo de dados.
Uma biblioteca livre chamada libogg está disponível para codificar e decodificar
dados de um stream Ogg.
O formato Ogg foi escolhido como container de dados por ser a melhor alternativa
livre disponível, com mais recursos e mais largamente testada.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
55
4.4.2 O Codec Vorbis
O Vorbis é um codec de áudio com perda para propósito geral, aberto e livre de
patentes. Foi desenvolvido e é mantido pela fundação Xiph.Org e foi concebido para
concorrer com o MP3 e o AAC. Ele é mais comumente usado juntamente com o container
Ogg, e juntos, ganham o nome Ogg Vorbis.
O Vorbis foi projetado para permitir uma grande flexibilidade de codificação e
também para permitir uma grande faixa de taxa de bits.
Ele é um codec monolítico que executa transformações adaptativas pra frente
(forwardadaptive) e é baseado na Transformada Discreta de Cosseno Modificada.
O Vorbis pode ser configurado para utilizar uma taxa de bits constante ou uma taxa de
bits variável.
Quando desejase utilizar uma taxa de bits constante, a opção “bitrate” deve ser
informada ao codec juntamente com o tamanho da taxa de bits. Esta opção força o codec a
adaptar a codificação a uma taxa de bits específica, que será mantida ao longo do tempo.
Para utilizarse uma taxa de bits variável, a opção “quality” deve ser informada ao
codec, acompanhada de um número fracionário entre 0 e 1. Juntamente com a opção
“quality” pode ser usada a opção “maxbitrate”, que define um teto para a quantidade de bits
por segundo quando se está utilizando uma taxa de bits variável.
O Vorbis foi escolhido como codec de áudio também por ser a melhor alternativa livre
disponível, com mais recursos e mais largamente testada.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
56
4.4.3 O Codec Theora
O Theora é um codec de vídeo com perda para propósito geral, aberto e livre de
patentes. Ele é baseado no VP3, da empresa On2, e foi desenvolvido para concorrer com os
codecs do padrão MPEG4, RealVideo e Windows Media. Apesar do VP3 ser patenteado, a
On2 tem permitido o seu uso livre de royalties, permitindo que o Theora e outros codecs
baseados nele sejam usados para qualquer propósito.
O Theora é mais comumente usado juntamente com o container Ogg e com o codec de
áudio Vorbis, formando o Ogg Vorbis/Theora. Estes três componentes juntos formam a
melhor opção multimídia entre as soluções existentes totalmente livres de patentes.
Tal como vários outros formatos de imagem e vídeo, o Theora usa subamostragem da
crominância, além de empregar o processo de estimativa/compensação de movimentos em
blocos e um bloco DCT 8x8. Isto é comparável ao padrão MPEG1/2/4. Além disso, o Theora
suporta quadros internos (intra coded) e quadros preditivos para frente (forward predictive),
mas não suporta quadros bipreditivos que podem ser encontrados em vários outros codecs de
vídeo.
Assim como o Vorbis, o Theora pode ser configurado para utilizar uma taxa de bits
constante ou uma taxa de bits variável. Quando desejase utilizar uma taxa de bits constante, a
opção “bitrate” deve ser informada ao codec juntamente com seu tamanho em bits. Para
utilizarse uma taxa de bits variável, a opção “quality” deve ser informada ao codec,
juntamente com um número de 0 a 63, que define a faixa desde a codificação mínima até a
máxima. Estas opções são mutuamente exclusivas.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
57
Outras opções relativas aos quadros de referência e sensibilidade à movimentação
também podem ser configuradas no Theora.
O Theora foi escolhido como codec de vídeo também por ser a melhor alternativa livre
disponível, com mais recursos e mais largamente testada.
4.4.4 O Framework Gstreamer
O Gstreamer é um framework bastante versátil, aberto e livre de patentes, voltado para
a criação de aplicações multimídia baseadas em streaming. A forma básica do Gstreamer se
baseia no pipeline1 do Oregon Graduate Institute, com algumas idéias do DirectShow.
O Gstreamer foi projetado para que aplicações para gerenciar vídeo e áudio (ou
ambos) sejam escritas facilmente. Além de vídeo e áudio, o Gstreamer também pode
processar qualquer tipo de fluxo de dados.
Um dos usos mais óbvios para o Gstreamer é a construção de um reprodutor
multimídia. Por padrão, ele já inclui componentes para construir um reprodutor com suporte a
vários formatos e codecs, incluindo MP3, Ogg/Vorbis, MPEG1/2, AVI, Quicktime, entre
outros. Entretanto, o Gstreamer é muito mais que um reprodutor multimídia. Sua principal
característica é que seus componentes podem ser mesclados e combinados através de
pipelines, tornando assim possível a criação de editores de áudio ou vídeo.
1 pipeline – Consiste em uma série de elementos de processamento organizados de forma que a saída de um elemento seja conectado à entrada do próximo.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
58
O framework é baseado em plugins que provêm codificação e decodificação de vários
codecs, entre outras funcionalidades. Conforme já foi dito, esses plugins são interligados
através de pipelines. São esses pipelines que controlam o fluxo de dados.
O GStreamer provê uma camada de abstração sobre componentes de manipulação para
qualquer formato para o qual haja um plugin instalado. Com ele, as aplicações não precisam
mais se preocupar em implementar decodificadores, mixers, sincronia ou codecs. Elas podem
se concentrar apenas nas funcionalidades mais úteis para o usuário. Essa abstração, é
representada na FIGURA 11.
O GStreamer é ainda multiplataforma e já roda nas seguintes arquiteturas e sistemas
operacionais: Linux x86, PPC, ARM, Solaris x86 e SPARC, MacOSX, Microsoft Windows e
IBM OS/400.
No Gstreamer, tudo começa com uma fonte (source) de fluxo de mídia, que pode ser
um arquivo, dados de áudio de um microfone ou da entrada da placa de som, dados de vídeo
capturado por uma webcam, por uma placa de captura de vídeo ou uma placa FireWire, um
FIGURA 11 – O Gstreamer perante seus plugins e outras aplicaçõesFonte: Lira (2006)
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
59
streaming da internet, entre outras fontes. O fluxo proveniente dessa fonte é recebido por um
consumidor (sink). Essa interligação entre os elementos é apresentada na FIGURA 12.
Na nomenclatura do Gstreamer, cada componente, exceto o fluxo, é um Elemento
(Element), e este deve ter pelo menos um source e um sink.
No meio do caminho do fluxo para seu destino, podem haver elementos que recebem o
fluxo em seu sink, façam alguma manipulação, e entreguem o resultado em seu source. Estes
elementos são chamados de filtros (filters) e sua utilização geralmente é necessária.
Sources e sinks são chamados conjuntamente de pads, que são as “portas” por onde
passa o fluxo. Eles possuem capacidades de manipulação de dados bem específicas e podem
restringir o tipo de dados que pode passar por eles. Os pads também fornecem informações
sobre suas capacidades para elementos que queiram se conectar a eles.
FIGURA 12 – Interligação de elementos do GstreamerFonte: Lira (2006)
FIGURA 16 – Demuxer de áudio e vídeoFonte: Lira (2006)
FIGURA 13 – Representação de pipeline para reproduzir Ogg com vídeo e áudioFonte: Lira (2006)
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
60
Interligando os diversos elementos do Gstreamer e seus plugins é possível criar
diversas aplicações. Na FIGURA 13 é apresentado um pipeline para reproduzir um arquivo já
salvo em formato Ogg, com um canal de vídeo Theora e um canal de áudio Vorbis. O
pipeline inicia com o elemento filesrc que lê um arquivo do disco. Posteriormente, a fonte
desse elemento é consumida pelo oggdemux que separa os canais de áudio e de vídeo do
container Ogg. Neste momento, é aberta uma thread (tarefa concorrente) para cada canal. Na
thread de vídeo, o elemento theoradec consome o vídeo do demuxer e o transforma em um
vídeo de espaço de cor YUV. Na seqüência, o filtro ffmpegcolorspace converte o vídeo
decodificado pelo theoradec no espaço de cor RGB, para que possa ser exibido na tela pelo
ximagesink. Na outra thread, o elemento vorbisdec consome o áudio do demuxer e o
transforma em um áudio do tipo com amostragem de ponto flutuante. Na seqüencia, o filtro
audioconvert transforma o áudio em amostragem inteira e em seguida é reamostrado pelo
audioresample para que possa ser reproduzido na placa de som pelo osssink.
A escolha do Gstreamer se deve ao fato de ser uma ferramenta com muitos recursos e
bastante flexibilidade, compatível com a codificação de formatos e codecs livres. Além disso,
o Gstreamer vem sendo constantemente aprimorado, e é o framework multimídia mais
completo e mais promissor que existe atualmente no mundo livre.
4.4.5 O Servidor Flumotion
O Flumotion é um servidor de streaming multimídia, aberto e livre de patentes. Ele é
escrito na linguagem Python e utiliza o framework Gstreamer para multimídia e o framework
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
61
Twisted1 para aplicações de redes de computadores. Em outras palavras, podese dizer que ele
é, entre outras coisas, uma interface operacional (frontend) para esses dois frameworks.
O Flumotion é uma ferramenta distribuída e extensível, e foi desenvolvida com o foco
principal de ser fácil de ser utilizado. Ele permite que o trabalho de captura, codificação,
empacotamento, distribuição e arquivamento seja feito por múltiplos computadores
denominamos trabalhadores (workers), e tudo isso seja gerenciado por um computador
denominado gerente (manager). Existe também uma ferramenta para administração do
gerente totalmente gráfica, com um assistente de configuração que facilita o trabalho de
produção de streaming. Além disso, o Flumotion tem uma arquitetura interna baseada em
componentes que fazem o trabalho desde a produção até a distribuição ou arquivamento. É
possível ainda, criar novos componentes ou alterar os já existentes com certa facilidade.
Para captura, o Flumotion possui componentes para FireWire (vídeo e áudio), placas
de captura de vídeo, webcams e placas de som, além de um componente que permite que parte
de um pipeline do Gstreamer seja utilizada como fonte de captura. Para codificação e
empacotamento, o Flumotion tem componentes para Theora, Vorbis e Speex, bem como um
componente que junta o áudio e o vídeo (ou apenas um deles) no formato Ogg. Possui
também componentes para distribuição de streaming e para gravar em disco. Além disso,
possui também componentes para equilíbrio de cores e overlay (sobreposição no vídeo) de
texto e imagem.
A FIGURA 14 apresenta um exemplo de uma tela de administração do Flumotion em
produção. O exemplo apresenta duas fontes de vídeo (“producervideo1” e “producer
video2”) e uma fonte de áudio (“produceraudio”). Cada uma das fontes de vídeo é codificada
para Theora pelo componentes “encodervideo1” e “encodervideo2” e a fonte de áudio,
1 Twisted – Framework dirigido a eventos para aplicações de rede escrito em Python de códigofonte aberto e livre de patentes.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
62
“encoderaudio” é codificada para Vorbis. Na seqüência, essas três fontes codificadas são
encapsuladas num arquivo Ogg através do componente “muxeraudiovideo”. Finalmente, o
arquivo Ogg é distribuído via streaming pelo componente “httpaudiovideo” e ao mesmo
tempo é armazenado pelo componente “diskaudiovideo”.
FIGURA 14 – Exemplo de tela de administração do Flumotion
A escolha do Flumotion se deve ao fato de ser uma ferramenta voltada para a
usabilidade, por ter interface amigável e também por ser bastante flexível. O Flumotion
também vem sendo constantemente aprimorado e se apresenta como a melhor ferramenta
livre de alto nível para streaming de vídeo e áudio.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
63
4.4.6 O applet Cortado
O Cortado é um applet em Java, capaz de decodificar Ogg com Vorbis e Theora,
aberto e livre de patentes.
O Cortado contém, internamente, uma série de componentes que são implementações
de algumas tecnologias para Java. O primeiro deles é o JST, uma implementação do
Gstreamer para Java. Há também o jcraft, que é uma implementação de Ogg (denominada
Jogg) e de Vorbis (denominada Jorbis) para Java. E ainda o jheora, uma implementação do
Theora para Java.
O Cortado não vem sendo mantido atualmente, sendo que a última alteração publicada
por sua equipe de desenvolvimento foi em 28/05/2007. Mesmo assim, ainda se apresenta
como uma solução viável para visualização de Ogg/Vorbis/Theora por rodar embutido em
uma página HTML (HyperText Markup Language) através de um plugin de Java.
Para a visualização, o applet Cortado foi o escolhido para ser adaptado, por ser o único
reprodutor multimídia livre de Ogg com Vorbis e Theora que roda embutido numa página
HTML. Com isso, é possível adicionar mais recursos a uma página HTML facilmente, como
um chat, por exemplo, e criar um ambiente de ensino à distância mais completo, sem exigir
mais do que um plugin de Java dos clientes.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
64
4.4.7 O distribuidor Icecast
O Icecast é um servidor de streaming multimídia aberto e livre de patentes, que
suporta a distribuição de Ogg (Vorbis e Theora) e também MP3. Atualmente, o Icecast roda
em GNU/Linux, FreeBSD, OpenBSD, Solaris e Microsoft Windows.
O Icecast funciona como um multiplicador, que recebe dados na forma de streaming e
multiplica o conteúdo para diversos clientes através de uma rede de computadores. Também é
possível utilizar diversos servidores Icecast para replicar streamings, colocando um servidor
como mestre e diversos outros como escravos, aumentando significativamente a largura de
banda disponível para a distribuição.
Internamente, o Icecast se baseia na biblioteca “libshout”, que é uma biblioteca de
comunicação que gerencia as conexões, o tempo dos dados e previne perda de dados.
Para a distribuição de streaming, dependendo da necessidade, a solução propõe o uso
do Flumotion ou do Icecast. A proposição de mais de uma ferramenta se deve a diversos
fatores. O primeiro deles é que o Gstreamer pode ser utilizado para captura e codificação
sozinho, sem o Flumotion, e como ele não faz a distribuição, uma outra ferramenta, como o
Icecast, é necessária. Outro fator muito importante é que o Icecast possui o recurso de
replicação de servidores, tornando possível o aumento da largura de banda, característica que
não é contemplada pelo Flumotion. Ainda é possível combinar as duas alternativas através de
um componente do Flumotion que envia dados para o Icecast, permitindo assim que o
Flumotion faça a distribuição para um rede interna, e que o Icecast faça a distribuição através
da Internet.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
65
4.4.8 Versões utilizadas
Na TABELA 4 são apresentadas todas as versões das tecnologias escolhidas que
foram utilizadas na implementação e nos testes. As versões citadas são as últimas publicadas
por cada projeto no momento deste trabalho. No caso do gstreamerpluginsbad, do Cortado e
do Flumotion, foi utilizada a versão de desenvolvimento, para que as alterações feitas por este
trabalho pudessem ser submetidas como contribuições para estes projetos.
TABELA 4 – Versões de tecnologias livres utilizadasTecnologia Versão
GNU/Linux Ubuntu 7.10
Ogg libogg 1.1.3
Vorbis libvorbis 1.2.0
Theora libtheora 0.0.0.alpha7
Gstreamer gstreamer 0.10.4.1, gstreamer0.10ffmpeg 0.10.2.2, gstreamer0.10pluginsbad (versão CVS1 do dia 14112007),gstreamer0.10pluginsbase 0.10.14.1,gstreamer0.10pluginsgood 0.10.6
Flumotion flumotion (versão SVN2 do dia 10112007)
Cortado cortado (versão SVN do dia 28052007)
Icecast icecast 2.3.5
1 CVS – (Concurrent Versions System) – Sistema de controle de versão que auxilia no desenvolvimento colaborativo de desenvolvedores espalhados geograficamente.
2 SVN – (Abreviação de Subversion) Sistema de controle de versão que auxilia no desenvolvimento colaborativo de desenvolvedores espalhados geograficamente. É uma evolução do CVS.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
66
4.5 Ferramentas proprietárias para ensino à distância
Existem algumas soluções no mercado que permitem a sincronização de imagens (ou
slides) com um streaming de vídeo e áudio. Além de fazer isso, essas ferramentas também
contam com outros recursos, tornando o ambiente virtual ainda mais próximo do real. Todas
estas soluções são proprietárias e, geralmente, têm um custo muito elevado. As mais
utilizadas são descritas a seguir. Todas estas ferramentas têm recursos semelhantes, voltados
principalmente à criação de salas de aula virtuais.
4.5.1 Adobe Acrobat Connect Professional
Entre as ferramentas que simulam o ambiente de sala de aula virtualmente, o Adobe
Acrobat Connect Professional, anteriormente conhecido como Macromedia Breeze, é o mais
utilizado (Wagner, 2006).
O Acrobat Connect Professional é uma solução de comunicação via Internet que
permite encontros virtuais, salas de aulas virtuais e colaboração em grupo, podendo ser
acessado em qualquer momento e de qualquer lugar, a partir de um navegador de Internet.
Entre suas principais características estão a disponibilização de conteúdo de slides do
Microsoft PowerPoint, vídeo e áudio ao vivo e sobdemanda, conteúdo Adobe Flash,
compartilhamento do ambiente de trabalho (captura de tela) ao vivo e chat multiusuário. A
FIGURA 15 apresenta o ambiente de trabalho do Adobe Acrobat Connect Professional.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
67
FIGURA 15 – Tela de demonstração do Adobe Acrobat Connect Professional
4.5.2 Microsoft Office Live Meeting
O Microsoft Office Live Meeting é um outra ferramenta comercial para conferência
via Web que permite encontros virtuais, treinamentos e eventos.
Entre suas principais características estão o compartilhamento de apresentação de
slides, envio e recebimento de vídeo e áudio, participação em chat, edição de arquivos e
compartilhamento de quadro branco. A FIGURA 16 apresenta a tela do Microsoft Office Live
Meeting.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
68
FIGURA 16 – Tela de demonstração do Microsoft Office Live Meeting
4.5.3 Wimba Classroom
O Wimba Classroom é uma ferramenta que permite ensinar e fazer encontros
virtualmente. Suas salas de aulas virtuais suportam áudio, vídeo, compartilhamento de
aplicações, conversas via chat e disponibilização de conteúdo.
A FIGURA 17 apresenta uma tela de demonstração do Wimba, que tem toda sua
interface via Web.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
69
FIGURA 17 – Tela de demonstração do Wimba Classroom
4.5.4 iLinc
O iLinc é um conjunto de ferramentas da empresa de mesmo nome (Ilinc
Communication), voltado para conferência via Web que permite encontros virtuais,
conferências, ensino à distância e prestação de suporte a clientes.
Entre suas principais características estão a transmissão de áudio e de vídeo, chat,
disponibilização de conteúdo, compartilhamento de aplicações e de quadro branco. A
FIGURA 18 apresenta uma tela de demonstração do LearnLinc, a ferramenta do conjunto
iLinc responsável pelo ensino à distância.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
70
FIGURA 18 – Tela de demonstração do LearnLinc
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
5 ESPECIFICAÇÃO DO AMBIENTE DE TRABALHO
A transmissão de vídeo e áudio através de um streaming pela Internet está se tornando
mais comum a cada dia. Atualmente, existem diversas ferramentas que fazem esse trabalho,
inclusive ferramentas livres de patentes e com padrões e códigosfonte abertos. Além disso,
novas tecnologias e novas ferramentas para essa área surgem e são aprimoradas
constantemente.
Porém, a maioria das ferramentas disponíveis, especialmente as livres, limitase a
transmitir apenas vídeo e áudio. Não é comum a existência de ferramentas livres com mais
recursos, que além de vídeo e áudio permitam, por exemplo, transferir imagens em qualidade
mais alta ao mesmo tempo que um vídeo e um áudio.
Outra questão importante a ser levantada é a largura de banda disponível,
principalmente no lado do cliente, que costuma ser relativamente pequena. Esta limitação
geralmente implica em transmissões que utilizam baixas taxas de bits, e conseqüentemente,
qualidades baixas, com vídeos de resolução em torno de 320x240. Com resoluções como essa
é inviável transmitir slides de uma apresentação, uma vez que pequenos elementos tornamse
ilegíveis.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
72
Para resolver os problemas citados acima, este trabalho apresenta uma solução baseada
na combinação e adaptação de algumas tecnologias livres, que tornam possível a utilização de
vídeo e áudio juntamente com a transmissão de slides sincronizados.
Esta solução simula um ambiente virtual de sala de aula nãointerativo, onde o aluno
pode ter virtualmente os mesmos recursos de visão e audição que tem presencialmente. Isto
faz com que esta solução seja ideal para utilização em ensino à distância.
Ela também permite a disponibilização de conteúdo em temporeal e sobdemanda.
Por exemplo, enquanto uma aula estiver ocorrendo, ela pode ser disponibilizada num
streaming em temporeal e ao mesmo tempo ser armazenada, para que os alunos que não
puderem assistir à aula ao vivo possam vêla posteriormente através de um streaming sob
demanda. Também é possível que seja apenas disponibilizada em temporeal ou apenas
gravada para ser disponibilizada futuramente.
Diversos recursos são necessários para a utilização desta solução. Para um melhor
entendimento, eles foram divididos nas áreas de captura, codificação, distribuição e
visualização.
5.1 Recursos para a captura
Para a utilização da solução, é necessária a utilização de uma fonte captadora de vídeo
e outra de áudio, de forma que a imagem e a voz possam ser codificadas e transmitidas via
streaming. Além disso, também é necessário capturar a imagem da apresentação de slides.
A seguir, cada uma destas fases de captura é detalhada.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
73
5.1.1 Captura de vídeo
Para a captura de vídeo é necessária a utilização de uma câmera, que poderá prover a
imagem através de sinais analógicos ou digitais. No caso da utilização de um sinal analógico,
é necessária a utilização de uma placa de captura de vídeo analógico, que digitaliza o sinal
analógico. Se a câmera for digital é possível utilizar uma conexão USB ou FireWire.
5.1.2 Captura de áudio
Para a captura de áudio, pode ser utilizado qualquer componente compatível com a
entrada de som das placas de som tradicionais, como um microfone ou uma saída de uma
mesa de som.
5.1.3 Captura de apresentação de slides
A captura do sinal de vídeo com os slides de uma apresentação é um pouco mais
complexa que as anteriores. Esta complexidade é um fator que contribui para que as
ferramentas livres existentes não contemplem esta característica.
A seguir são apresentadas três formas possíveis para a captura de slides. A discussão
sobre vantagens e desvantagens de cada uma é apresentada no Capítulo 7.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
74
5.1.3.1 Captura da saída de vídeo do computador
A primeira alternativa para a captura dos slides é através da saída de vídeo do
computador.
Como pode ser visto no esquema da FIGURA 19, existem cinco formas para o sinal da
saída de vídeo do computador que apresenta os slides chegar até o computador produtor
(computador onde ocorre a captura e a codificação).
FIGURA 19 – Esquema para capturar a saída de vídeo do computador
Duas dessas formas estão atreladas à saída analógica SVideo1 da placa de vídeo do
computador que contém a apresentação de slides. Um caminho possível utilizando essa saída
é ligála diretamente a uma placa de captura de vídeo analógico, conectada ao computador
1 SVideo – (Separate Video) – Padrão de vídeo analógico que separa os dados em sinais de brilho e cor. Este padrão é erroneamente confundido com SVHS e Super Video.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
75
produtor. O outro caminho possível é utilizar um equipamento que converte este sinal
analógico para digital (FireWire), e este por sua vez, ser conectado a uma placa FireWire no
computador produtor.
As outras três formas estão atreladas à saída VGA1 da placa de vídeo do computador
apresentador de slides. Destas três formas, duas passam por um equipamento conversor de
VGA para SVideo. A partir da saída analógica desse conversor, o caminho é semelhantes às
duas formas comentadas anteriormente, ou seja, através da placa de captura de vídeo
analógico ou através de um conversor de analógico para digital. A terceira forma utilizando a
saída VGA é utilizar um conversor de VGA para FireWire.
Destas cinco formas, as quatro que estão atreladas a um sinal SVideo, seja na saída do
computador ou na saída do conversor de VGA para analógico, sofrem degradação de
qualidade, uma vez que os computadores geralmente utilizam resoluções superiores a
800x600, e a resolução equivalente de um sinal SVideo está em torno de 640x480, sem
contar a degradação de qualidade que ocorre devido ao ruído gerado pelo canal analógico. No
caso da utilização do equipamento conversor de VGA para FireWire, esse problema é
minimizado, uma vez que o sinal VGA pode ser convertido pra FireWire mantendose uma
resolução mais alta e minimizandose o ruído.
1 VGA – (Video Graphis Array) – Padrão analógico de exibição para computadores. Este termo também representa o conector de 15 pinos presente nas placas de vídeo, mais comumente usado para conectar um monitor de vídeo.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
76
5.1.3.2 Captura do ambiente de trabalho compartilhado via RFB
A segunda alternativa possível é a utilização de um ambiente compartilhado,
utilizando o protocolo RFB1, utilizado em servidores e visualizadores de VNC2.
Na FIGURA 20 é apresentado o esquema para captura através do protocolo RFB, da
codificação, da distribuição e da visualização.
Esta forma exige que haja uma conexão de rede entre o computador apresentador de
slides e o computador produtor, bem como um servidor RFB instalado no apresentador de
slides.
Em termos de qualidade, esta forma é excelente, pois não há nenhuma degradação no
processo, uma vez que a captura é inteiramente digital.
1 Protocolo RFB (Remote Framebuffer) – Protocolo simples para acesso remoto utilizando interfaces gráficas.2 VNC – (Virtual Networking Computing) – Sistema de compartilhamento de ambiente de trabalho que utiliza
o protocolo RFB para visualizar e controlar outros computadores através da rede, passando em um sentido a informação visual, e no outro os eventos de dispositivos de entrada como mouse e teclado.
FIGURA 20 – Esquema para capturar o ambiente compartilhado via RFB
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
77
5.1.3.3 Captura do ambiente de trabalho compartilhado via chamadas ao modo gráfico
do GNU/Linux
A terceira alternativa possível é a utilização de um ambiente compartilhado utilizando
o modo gráfico do GNU/Linux1.
Na FIGURA 21 é apresentado o esquema para captura através de chamadas ao modo
gráfico do GNU/Linux, da codificação, da distribuição e da visualização.
Esta forma difere das anteriores uma vez que a apresentação dos slides, a captura e a
codificação acontecem no mesmo computador. Obviamente, essa técnica requer mais recursos
de hardware, sendo discuta no Capítulo 7.
FIGURA 21 – Esquema para capturar o ambiente compartilhado via chamadas ao modo gráfico do GNU/Linux
Em termos de qualidade, esta forma também é excelente, pois também não há
nenhuma degradação no processo, uma vez que o processo também é inteiramente digital.
1 GNU/Linux – Sistema Operacional livre mais utilizado no mundo
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
78
Das três formas apresentadas, esta é a única que depende de um sistema operacional
específico, no caso, o GNU/Linux.
5.2 Recursos para a codificação
Para fazer a codificação de vídeo e áudio depois destes já terem sido capturados, é
necessária a utilização de um computador com o sistema operacional GNU/Linux, com os
pacotes Gstreamer e Flumotion instalados. Estas ferramentas fazem tanto a captura quanto a
codificação.
A codificação é feita para o formato Ogg, utilizando o codec Vorbis para áudio e
Theora para vídeo. Dentro do container Ogg, são colocados um canal de áudio e dois canais
de vídeo, sendo um da câmera de vídeo e outro da apresentação de slides. A sincronização é
garantida pelo próprio container Ogg, desde que não haja atraso na captura em relação ao
outro sinal de vídeo e ao áudio. Os dois vídeos são injetados no container com resoluções,
número de quadros por segundo e qualidades diferentes. A discussão desses parâmetros que
resultam em diferentes qualidades e diferentes necessidades de largura de banda, bem como
os resultados obtidos são apresentados no Capítulo 7.
5.3 Recursos para a distribuição
Para fazer a distribuição do conteúdo codificado através de streaming, é possível
utilizar duas ferramentas: o Flumotion e o Icecast.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
79
Este computador pode ser o mesmo que captura e codifica os dados. É possível, por
exemplo, que o computador produtor esteja dentro de uma rede interna e o computador
distribuidor visível pela Internet. Também é possível que tanto a produção quanto a
distribuição sejam feitas no mesmo computador. Caso dois computadores sejam utilizados, é
possível que o produtor também faça o trabalho de distribuição para uma rede interna e o
distribuidor faça a distribuição para a Internet. É possível ainda, a utilização de replicadores
de distribuição, caso seja necessário aumentar a largura de banda disponível para atender os
visualizadores. Todos estes cenários são discutidos nos Capítulos 6 e 7.
5.4 Recursos para a visualização
Para a visualização do conteúdo do streaming, podese utilizar o applet em Java
modificado por este trabalho. Dentre os reprodutores multimídia compatíveis com os formatos
livres, o VLC1 foi o único que se manteve compatível com os dois vídeos encapsulados no
Ogg.
A compatibilidade do Cortado depende de um plugin de Java instalado no navegador
de Internet. O Java é compatível com os principais sistemas operacionais, tornando o Cortado
possível de ser exibido por praticamente qualquer navegador do mercado. Como o applet é
embutido numa página HTML, ele pode ser facilmente integrado com outros recursos, como
ferramentas de chat por exemplo, que também podem ser embutidas em páginas HTML.
Utilizando esses dois recursos, criase uma solução ainda mais completa para utilização em
ensino à distância, pois adiciona recursos de interatividade e colaboração.
1 VLC (VideoLan Client) – Reprodutor multimídia multiplataforma livre para os principais formatos de containers e codecs do mercado. Também pode ser usado como servidor de streaming.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
80
O VLC pode ser uma boa alternativa caso o cliente queira utilizar um software
compilado para a arquitetura de seu sistema operacional a fim de consumir menos recursos de
memória e processamento.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
6 DETALHAMENTO DA IMPLEMENTAÇÃO
A proposta deste trabalho é apresentar uma solução livre em um ambiente em que seja
possível transmitir slides de uma apresentação juntamente com um streaming de vídeo e
áudio, com boa qualidade, pouca largura de banda e o mínimo de interferência no ambiente do
cliente.
Diante disso, um dos principais problemas a ser resolvido por este trabalho é a
definição de como os slides podem ser capturados e também como podem ser encapsulados
num streaming, mantendo uma sincronia com o áudio e com o vídeo.
Para atender a estas necessidades, foram feitos diversos testes e combinações de
ambientes e tecnologias livres, a fim de obter um resultado flexível e que atendesse os
requisitos citados acima.
A seguir é feito o detalhamento da implementação em cada um dos estágios do
streaming, bem como o detalhamento dos cenários completos desde a produção até a
distribuição.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
82
6.1 O estágio de captura
A captura de áudio de um microfone ou da entrada de linha da placa de som, bem
como a captura de câmeras FireWire, webcams ou placas de captura de vídeo analógica são
problemas bem resolvidos pelas tecnologias apresentadas em suas características originais.
Para a captura dos slides, diversas formas foram pesquisadas a fim de se ter uma
solução flexível. Três formas de captura dos slides foram desenvolvidas. Estas formas se
diferem umas das outras apenas na captura, pois a partir do estágio de codificação, as
implementações são semelhantes para as três.
A seguir são detalhadas as implementações de cada uma das três formas de captura de
slides desenvolvidas.
6.1.1 Captura da saída de vídeo do computador
A primeira forma desenvolvida foi a captura da saída de vídeo do computador, através
de um conector VGA ou SVideo. Como esta forma atua direto na saída de vídeo, existe a
independência de sistema operacional e não há nenhuma interferência no ambiente de
trabalho do cliente.
Nessa primeira forma, para o estágio de captura, não foi necessário nenhuma
implementação em termos de código, já que o Flumotion e o Gstreamer já suportam fontes de
placas de captura de vídeo analógico e de placas FireWire.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
83
Foram pesquisadas diversas maneiras de se capturar esta saída de vídeo do
computador, bem como os equipamentos que são necessários para fazer esta captura.
No caso mais simples, quando o computador tiver uma saída SVideo, basta ligar esta
saída a uma placa de captura de vídeo analógico. Também é possível digitalizar esse sinal
antes deste chegar ao computador produtor, utilizando um conversor de SVideo para
FireWire, como o Canopus ADVC100, que é apresentado na FIGURA 22.
Para utilizar a saída VGA, é possível que o sinal chegue ao computador produtor de
três formas. A primeira delas consiste em utilizar um conversor de VGA para SVideo,
ligando essa saída à placa de captura de vídeo analógico. Para essa forma, podese usar o
conversor PixelView Game Show, que é apresentado na FIGURA 22. Também é possível que
esse sinal SVideo seja conectado ao Canopus ADVC100 para ser transformado para
FireWire, para então ser conectado ao computador produtor. A última e melhor forma é ligar a
saída VGA a um conversor de VGA para FireWire, como o Canopus TwinPact 100. De todas
as formas, esta é a que apresenta melhor qualidade, pois o conversor de VGA para FireWire
mantém a resolução alta do sinal VGA, porém este conversor custa cerca de dez vezes mais
que o conversor de VGA para SVideo.
FIGURA 22 – Exemplos de conversores de vídeo
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
84
6.1.2 Captura do ambiente de trabalho compartilhado via RFB
A segunda forma desenvolvida foi capturar um ambiente de trabalho compartilhado
através do protocolo RFB, utilizado por ferramentas de VNC. Para o funcionamento dessa
forma, existe a dependência de um servidor VNC rodando no computador em que os slides
serão apresentados. Estas ferramentas são muito difundidas e existem soluções livres e sem
custo para os principais sistemas operacionais utilizados atualmente. Além disto, também é
necessária uma conexão de rede entre os computadores.
Para esta forma ser desenvolvida, foram necessárias algumas alterações no
componente “librfb” do Gstreamer, que é disponibilizado pela série “gstreamerpluginsbad”.
Esta série do Gstreamer é caracterizada por diversos componentes livres de patentes, que
ainda não atingiram funcionalidades ou qualidade de código suficientes, ou são deficientes de
documentação.
O componente “librfb” é caracterizado por capturar o ambiente através do protocolo
RFB e disponibilizar como saída um vídeo no padrão RGB, com resolução entre 16x16 e
4096x4096 e com uma taxa de quadros variável.
Na LISTAGEM 1 é apresentado um exemplo da parte de captura de vídeo de um
pipeline do Gstreamer a partir de uma fonte RFB (componente rfbsrc, do “librfb”), sendo
transformado em um vídeo do padrão YUV (componente ffmpegcolorspace), sendo
diminuído ou aumentado para uma resolução de 640x480 (componente ffvideoscale) e sendo
transformado em uma taxa fixa de 3 quadros por segundo (componente videorate). Na forma
anterior, onde é feita a captura da saída de vídeo do computador, estes parâmetros podem ser
definidos em mais alto nível pelo Flumotion.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
85
rfbsrc host=192.168.0.180 password=SENHA keep-alive=true keep-alive-rate=0.3 ! ffmpegcolorspace ! ffvideoscale ! video/x-raw-yuv,width=640,height=480 ! videorate ! video/x-raw-yuv,framerate=3/1
LISTAGEM 1 – Exemplo de pipeline do Gstreamer para captura via RFB
Como as opções de saída do “librfb” são fixas, e o Theora não suporta taxa de quadros
variável, foram necessárias algumas alterações no “librfb” para que o componente
intermediário “videorate” (da série “base” do Gstreamer) pudesse transformar uma taxa de
quadros variável em uma taxa de quadros fixa.
O componente “videorate” é caracterizado por descartar, duplicar e ajustar o tempo de
quadros. Ele pode receber qualquer taxa de quadros na entrada e é capaz de disponibilizar
qualquer taxa de quadros na saída, desde que receba dados constantemente da entrada.
No Apêndice 1 é apresentado um código desenvolvido para o componente “librfb”
que soluciona esta questão.
Basicamente foram necessárias duas alterações estruturais.
A primeira foi definir o timestamp1 de cada quadro para que o “videorate” pudesse
trabalhar corretamente, uma vez que os quadros do “librfb” estavam chegando sem marcação
de tempo.
A segunda foi criar um novo recurso para o “librfb” chamado “keepalive”, que força
o protocolo RFB a enviar dados constantemente conforme taxa de tempo especificada (nova
opção criada, chamada de “keepaliverate”). Isso foi necessário porque o protocolo RFB é
caracterizado por só enviar dados ao cliente RFB, neste caso o Gstreamer, quando houver
alterações na tela. Como numa apresentação de slides é muito comum que a tela fique estática
1 Timestamp – Seqüência de caracteres que denota tempo (geralmente em frações de segundo) de algum evento ocorrido.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
86
por um longo tempo, foi criada esta opção para injetar dados constantemente ao “videorate”
para que este funcione corretamente e consiga desempenhar seu papel de transformar uma
taxa de quadros variável em fixa. O recurso “keepalive” foi desenvolvido abrindose uma
nova thread interna no Gstreamer dentro do “librfb”, que força a atualização conforme uma
taxa de tempo especificada em segundos.
Como estas duas macro alterações foram feitas em momentos diferentes, a primeira
delas foi enviada aos desenvolvedores do Gstreamer e já foi publicada oficialmente em
15/11/2007. A segunda parte foi enviada, mas não foi publicada até a data de elaboração deste
trabalho.
6.1.3 Captura do ambiente de trabalho compartilhado via chamadas ao modo gráfico
do GNU/Linux
A terceira forma possível para captura de slides é através do uso de um componente da
série “good” do Gstreamer chamado “ximagesrc”.
Este componente é caracterizado por fazer a captura da tela através de chamadas ao
modo gráfico do GNU/Linux usando chamadas à biblioteca Xlib1.
Esta forma tem duas características principais que a diferenciam das outras duas já
especificadas. A primeira característica é a dependência de um sistema operacional, o
GNU/Linux, com qualquer uma de suas distribuições. A segunda característica é que nessa
forma o computador que apresenta os slides e o computador produtor e codificador devem ser
1 Xlib – Biblioteca cliente que contém funções que interagem com o servidor gráfico padrão do GNU/Linux, o X server. Ela funciona como uma camada de abstração entre as aplicações gráficas e o servidor gráfico.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
87
o mesmo. Esta pode ser uma boa opção para computadores pessoais que tenham câmera
embutida ou via USB, pois não há dependência de outros recursos. É uma opção ideal, por
exemplo, para um professor gravar uma aula em seu laptop.
Não foi necessária nenhuma implementação ou alteração para a utilização dessa forma
de captura dos slides. A razão disso é que o componente “ximagesrc” entrega em sua saída
um vídeo usando o padrão RGB, com qualquer resolução e com uma taxa de quadros fixa.
Na LISTAGEM 2 é apresentado um exemplo da parte de captura de vídeo de um
pipeline do Gstreamer utilizando o “ximagesrc” e desabilitandose a extensão XDamage1,
com uma taxa fixa de 3 quadros por segundo, sendo transformado em um vídeo do padrão
YUV (componente ffmpegcolorspace), cortandose 112 pixels de cada lado (componente
videocrop; os testes foram feitos em um computador com tela widescreen2) e sendo diminuído
ou aumentado para uma resolução de 640x480 (componente ffvideoscale).
ximagesrc use-damage=false ! video/x-raw-rgb,framerate=3/1 ! ffmpegcolorspace ! videocrop left=112 right=112 ! ffvideoscale ! video/x-raw-yuv,width=640,height=480
LISTAGEM 2 – Exemplo de pipeline do Gstreamer para captura via Xlib
1 XDamage – Extensão que permite que aplicações gerenciem apenas as modificações da tela, ou seja, que não releiam toda a tela a cada vez. Nos testes realizados esta extensão não se mostrou perfeitamente compatível com o componente “ximagesrc”, e por isso, sugerese que não seja utilizada. O fato de utilizar ou não esta extensão não interfere na demanda de processamento.
2 Widescreen – Formato de tela que tem proporção de 16:9. Atualmente, é mais comum os monitores de vídeo utilizarem uma tela de proporção 4:3, aspecto comumente utilizado por câmeras de vídeo.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
88
6.2 O estágio de codificação
Depois de capturados, os slides precisam, de alguma forma, ser combinados com o
áudio e com o vídeo para posteriormente serem distribuídos, mantendose a sincronização
destes três componentes.
Uma preocupação significativa deste trabalho foi montar um cenário em que esse
problema fosse resolvido. Isto foi feito sem que nenhuma alteração fosse necessária nas
tecnologias escolhidas.
Como o container Ogg suporta múltiplos canais de áudio e de vídeo, os slides foram
encapsulados no Ogg como um segundo canal de vídeo. Se o estágio de captura garante que
as duas fontes de vídeo (slides e câmera) e a fonte de áudio sejam capturadas corretamente e
constantemente, conforme já foi explicado, o próprio container Ogg garantirá que estes três
componentes permaneçam sincronizados ao longo do tempo.
Na LISTAGEM 3 é apresentada a saída do comando “oggzinfo”, do oggztools1,
aplicado a um arquivo Ogg contendo os componentes citados acima.
Theora: serialno 1518059340 Video-Framerate: 3.000 fps Video-Width: 640 Video-Height: 480
Theora: serialno 0884191019 Video-Framerate: 6.250 fps Video-Width: 320 Video-Height: 240
Vorbis: serialno 0358904338 Audio-Samplerate: 48000 Hz Audio-Channels: 2
LISTAGEM 3 – Saída do comando “oggzinfo” para Ogg com dois canais de vídeo
1 oggztools – Conjunto de utilitários (comandos) para análise e correções em arquivos Ogg
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
89
Como pode ser observado neste exemplo, o arquivo Ogg é composto de dois vídeos e
um áudio, representados por seus codecs. O primeiro canal de vídeo contém os slides, com
uma taxa de 3 quadros por segundo e uma resolução de 640x480. O segundo vídeo contém as
imagens da câmera, com uma taxa de 6,25 quadros por segundo, com resolução de 320x240.
O áudio contém uma taxa de 48.000 amostras e 2 canais de áudio.
A forma como que isso é feito na prática é descrita na Seção 4.5, que apresenta os
cenários completos desde a captura até a distribuição. Nesta seção também são apresentados
todos os parâmetros que podem ser configurados para a codificação do vídeo, como taxa de
quadros por segundo, resolução e qualidade (VBR) ou taxa de bits (CBR), e para a
codificação de áudio, como taxa de amostras por segundo, número de canais e qualidade
(VBR) ou taxa de bits (CBR).
6.3 O estágio de distribuição
Depois de capturados e encapsulados, os dados precisam ser distribuídos através de
uma rede de computadores para que possam ser visualizados por múltiplos clientes.
Conforme já foi dito, esta distribuição pode ser feita utilizandose duas ferramentas
individualmente ou em conjunto. Essas ferramentas são o Flumotion e o Icecast, e não foi
necessária fazer nenhuma implementação ou alteração para que funcionassem com o ambiente
completo desenvolvido neste trabalho. A configuração de cada um destes componentes é
descrita na seção a seguir.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
90
6.4 Os cenários completos desde a captura até a distribuição
Uma vez que os estágios de captura, codificação e distribuição estão especificados, é
necessário definir como estes estágios se interligam. Geralmente, essa interligação ocorre num
mesmo computador, mas a Flumotion permite que estas tarefas sejam executadas por
múltiplos computadores, através de múltiplos “workers”.
Nos cenários descritos a seguir, as tarefas de captura e codificação são feitas pelo
mesmo computador. Em alguns cenários, a distribuição é feita pelo mesmo computador
também, e em outros, por um segundo computador.
6.4.1 O cenário de captura da saída de vídeo do computador
Este primeiro cenário será descrito completamente. Os cenários a seguir serão
descritos como complementação deste cenário e dos demais que forem sendo descritos. Todos
os exemplos de cenários completos, com exceção desse primeiro, podem ser encontrados no
Capítulo de Apêndices. Nos apêndices também podem ser encontrados exemplos de cenários
completos, utilizandose apenas o Gstreamer e o Icecast, sem a presença do Flumotion.
Como o Flumotion, em sua interface gráfica de configuração original não permite que
sejam incorporados dois canais de vídeo e um de áudio num container Ogg, estes cenários
precisam ser montados em arquivos XML1 e importados a partir da interface gráfica do
Flumotion.
1 XML (eXtensible Markup Language) – É uma linguagem de marcação capaz de descrever diversos tipos de dados. Seu propósito principal é a facilidade de compartilhamento de informações através da Internet.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
91
Este cenário captura o áudio de um microfone, o vídeo de uma webcam, o vídeo com
os slides por uma placa de captura de vídeo analógico, faz a codificação para Ogg com Vorbis
e Theora e distribui em temporeal, via streaming através da rede, enquanto que ao mesmo
tempo armazena o streaming em disco para posteriormente ser distribuído sobdemanda.
Na LISTAGEM 4 é apresentado o arquivo de configuração em XML do Flumotion
para este cenário.
<?xml version="1.0" ?> <planet> <flow name="default"> <component name="producer-video1" project="flumotion" type="pipeline-producer" version="0.5.0.1" worker="localhost">
<property name="pipeline">v4l2src device=/dev/video1 ! video/x-raw-yuv,width=640,height=480 ! ffvideoscale ! video/x-raw-yuv,width=640,height=480 ! videorate ! video/x-raw-yuv,framerate=3/1</property> </component>
<component name="producer-video2" project="flumotion" type="webcam-producer" version="0.5.0.1" worker="localhost">
<property name="device">/dev/video0</property> <property name="element-factory">v4lsrc</property> <property name="format">I420</property> <property name="framerate">100/16</property> <property name="height">240</property> <property name="mime">video/x-raw-yuv</property> <property name="width">320</property> </component>
<component name="encoder-video1" project="flumotion" type="theora-encoder" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>producer-video1</feed> </eater>
<property name="quality">32</property> </component>
<component name="encoder-video2" project="flumotion" type="theora-encoder" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>producer-video2</feed> </eater>
<property name="quality">16</property> </component>
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
92
<component name="producer-audio" project="flumotion" type="soundcard-producer" version="0.5.0.1" worker="localhost">
<property name="channels">2</property> <property name="depth">16</property> <property name="device">/dev/dsp</property> <property name="rate">48000</property> <property name="source-element">osssrc</property> </component>
<component name="encoder-audio" project="flumotion" type="vorbis-encoder" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>producer-audio</feed> </eater>
<property name="quality">0.1</property> </component>
<component name="muxer-audio-video" project="flumotion" type="ogg-muxer" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>encoder-video1</feed> <feed>encoder-video2</feed> <feed>encoder-audio</feed> </eater> </component>
<component name="http-audio-video" project="flumotion" type="http-streamer" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>muxer-audio-video</feed> </eater>
<property name="burst-on-connect">True</property> <property name="client-limit">500</property> <property name="mount-point">/</property> <property name="port">8800</property> </component>
<component name="disk-audio-video" project="flumotion" type="disk-consumer" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>muxer-audio-video</feed> </eater>
<property name="directory">/tmp</property> <property name="rotate-type">time</property> <property name="start-recording">True</property> <property name="time">43200</property> </component>
</flow> </planet>
LISTAGEM 4 – Arquivo XML do Flumotion para forma de captura da saída de vídeo do computador
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
93
O arquivo XML do Flumotion é caracterizado por uma série de componentes com
propriedades internas, que são os parâmetros configuráveis propriamente ditos. Estes
componentes se interligam através da tag <source> com o conteúdo representado pelo nome
do componente anterior que deve ser conectado ao componente atual.
Os componentes que têm o prefixo “producer”, fazem parte do estágio de captura. Os
componentes com o prefixo “encoder” e “muxer” fazem parte do estágio de codificação. Os
componentes com o prefixo “http” e “disk” fazem parte do estágio e distribuição e de
armazenamento em disco, respectivamente.
Neste exemplo, o componente “producervideo1” utiliza um componente interno
especial do Flumotion, onde é possível colocar pipelines do Gstreamer para fazer a captura de
vídeo ou de áudio. Este exemplo está capturando os slides através de uma placa de captura de
vídeo analógico no padrão YUV (dispositivo identificado como “/dev/video1” pelo
GNU/Linux), diminuindo ou aumentando o vídeo para a resolução de 640x480 e com taxa de
3 quadros por segundo.
O componente “producervideo2” captura o vídeo de uma webcam USB (dispositivo
identificado como “/dev/video0” pelo GNU/Linux), com resolução de 320x240 e 6,25
(100/16) quadros por segundo. Esta configuração foi obtida através da interface gráfica de
webcams do Flumotion e, posteriormente, exportado para XML.
O componente “produceraudio” captura um áudio de 2 canais (estéreo) da placa de
som, com profundidade de 16 bits e taxa de 48.000 amostras por segundo. A configuração
desse componente também foi obtida pela interface gráfica do Flumotion.
Os componentes “encodervideo1” e “encodervideo2” codificam o vídeo contendo
os slides e a imagem da webcam para Theora, com as qualidades 32 e 16, respectivamente. O
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
94
componente “encoderaudio”, codifica o áudio para Vorbis com a qualidade 0.1. Nos três
casos, são gerados streamings VBR. Para se gerar streaming CBR, basta excluir o parâmetro
“quality” e adicionar o parâmetro “bitrate” em cada um dos codificadores. A configuração
dos parâmetros “quality” e “bitrate”, bem com as melhores relações custo x benefício para
cada necessidade, são apresentadas no Capítulo 7.
Depois de codificados, os dois vídeos e o áudio são juntados no arquivo Ogg, pelo
componente “muxeraudiovideo”.
Posteriormente, o arquivo Ogg é obtido por dois outros componentes. O primeiro,
chamado “httpaudiovideo”, disponibiliza esse arquivo via streaming através da rede na porta
8800, com limite de 500 visualizadores. O segundo é o “diskaudiovideo” que armazena o
arquivo Ogg em disco rígido, no diretório “/tmp” e cria um novo arquivo a cada 43200
segundos, ou seja, a cada 12 horas. A configuração destes dois componentes foi obtida através
da interface gráfica do Flumotion. Caso não seja necessário distribuir ou armazenar o
streaming, basta excluir o componente respectivo.
6.4.2 O cenário de captura da saída do ambiente compartilhado via RFB
Este cenário difere do anterior apenas na forma de captura dos slides. Para isto, basta
alterar o componente “producervideo1” no arquivo XML, como é mostrado na LISTAGEM
5.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
95
<component name="producer-video1" project="flumotion" type="pipeline-producer" version="0.5.0.1" worker="localhost"> <property name="pipeline"> rfbsrc host=192.168.0.180 password=SENHA keep-alive=true keep-alive-rate=.3 ! ffmpegcolorspace ! ffvideoscale ! video/x-raw-yuv,width=640,height=480 ! videorate ! video/x-raw-yuv,framerate=3/1 </property> </component>
LISTAGEM 5 Parte do XML para captura via RFB
6.4.3 O cenário de captura da saída do ambiente compartilhado via chamadas ao modo
gráfico do GNU/Linux
Este cenário também difere dos anteriores apenas quanto à etapa de captura dos slides.
Para isto, basta alterar o componente “producervideo1” no arquivo XML, como é mostrado
na LISTAGEM 6.
<component name="producer-video1" project="flumotion" type="pipeline-producer" version="0.5.0.1" worker="localhost"> <property name="pipeline"> ximagesrc use-damage=false ! video/x-raw-rgb,framerate=3/1 ! ffmpegcolorspace ! videocrop left=112 right=112 ! ffvideoscale ! video/x-raw-yuv,width=640,height=480 </property> </component>
LISTAGEM 6 – Parte do XML para captura via Xlib
6.4.4 O cenário de distribuição utilizando o Icecast
Conforme já foi dito, é possível também que se use o Icecast para fazer a transmissão
do streaming.
Basta adicionar o conteúdo apresentado na LISTAGEM 7 no arquivo XML. Diante
desse componente, é possível excluir, caso haja necessidade, os componentes “httpaudio
video” e “diskaudiovideo”.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
96
<component name="shout2-audio-video" project="flumotion" type="shout2-consumer" version="0.5.0.1" worker="localhost"> <source>muxer-audio-video</source>
<property name="ip">192.168.0.1</property> <property name="password">hackme</property> <property name="mount-point">/ead.ogg</property> <property name="port">8000</property> </component>
LISTAGEM 7 – Parte do XML para distribuição via Icecast
Este exemplo funciona com a configuração padrão do Icecast.
6.5 O estágio de visualização
Uma vez que os dois canais de vídeo estão encapsulados no container Ogg, é
necessário fazer com que possam ser exibidos, utilizando apenas uma conexão com o servidor
de streaming.
Para tornar isso possível, foram feitas diversas alterações no applet Cortado. O patch
completo pode ser visto no Apêndice 2 e o resultado final é demonstrado na FIGURA 23.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
97
FIGURA 23 – Applet Cortado adaptado
A primeira alteração feita no Cortado foi a definição de novos parâmetros que podem
ser passados ao applet via HTML. Cinco novos parâmetros foram criados: “videoChannels”,
“keepDimension”, “background”, “coordinate”, “coordinate1”.
O primeiro parâmetro criado foi o “videoChannels”. A partir desse parâmetro, é
possível informar ao Cortado quantos vídeos ele exibirá, desde que estejam disponíveis. Os
valores possíveis para esse parâmetro são “1” e “2”.
Por padrão, o Cortado redimensiona o vídeo para o tamanho do applet,
independentemente do tamanho original do vídeo. Se dois vídeos precisam ser exibidos
simultaneamente, isto passa a ser um problema, pois um vídeo sobreporia o outro. Para
resolver essa questão, foi criado foi o “keepDimension”, que preserva o tamanho original do
vídeo, desde que este não exceda o tamanho do applet. Por padrão, esse valor é marcado
como falso, para manter as características originais do Cortado.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
98
O terceiro parâmetro criado foi o “background”. Esse parâmetro foi criado para
preencher o fundo preto com uma imagem, especialmente para quando dois vídeos de
tamanhos diferentes são exibidos, pois neste caso é impossível ocupar todo o espaço
disponível no applet. A utilização desse recurso fica clara na FIGURA 24, em que a imagem
de fundo tem a cor azul predominantemente. Também é possível utilizar esse recurso com
apenas um canal de vídeo, desde que seja utilizado juntamente com o parâmetro
“keepDimension”. Este parâmetro incorpora o recurso de personalização da identidade visual
do Cortado. Por padrão, esse valor é definido como nulo.
Os dois últimos parâmetros criados são o “coordinate” e o “coordinate1”. Estes
parâmetros definem as coordenadas x e y que marcam o ponto superior esquerdo, a partir de
onde os vídeos serão desenhados. Para o funcionamento destes parâmetros também é
necessário que o “keepDimension” seja definido como verdadeiro. Estes parâmetros recebem
valores correspondentes a um ponto no espaço bidimensional, na forma de “3,10”, por
exemplo, que identificam x e y, respectivamente.
Com a combinação destes parâmetros, tornase possível a exibição das soluções
propostas por este trabalho.
Na LISTAGEM 8 é apresentado um exemplo do código HTML de uma página
utilizando o Cortado com estes novos parâmetros. Os demais parâmetros apresentados que são
passados ao applet são nativos do Cortado.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
99
<html> <body leftmargin="0" topmargin="0" marginwidth="0" marginheight="0"> <applet code="com.fluendo.player.Cortado.class" archive="cortado-ovt.jar" width="980" height="510"> <param name="url" value="http://strninja/streamAnalog.ogg"/> <param name="local" value="false"/> <param name="keepAspect" value="true"/> <param name="keepDimension" value="true"/> <param name="seekable" value="true"/> <param name="live" value="false"/> <param name="duration" value="582"/> <param name="video" value="true"/> <param name="audio" value="true"/> <param name="showStatus" value="show"/> <param name="bufferSize" value="100"/> <param name="coordinate" value="334,7"/> <param name="coordinate1" value="5,107"/> <param name="videoChannels" value="2"/> <param name="background" value="http://strninja/back.png"/> </applet>
</body> </html>
LISTAGEM 8 – Código HTML para exibição do applet Cortado
Além da adição destes parâmetros, foram necessárias algumas alterações na estrutura
interna do Cortado.
A primeira grande alteração feita foi a criação de variáveis para controle do segundo
vídeo, assim como já existia para o primeiro. Para a sincronização e acionamento do áudio e
do vídeo, dentro do Cortado é feito um laço, que é iterado no início da execução tantas vezes
quanto o número de componentes encapsulados no Ogg. Dentro deste laço, é testado o tipo de
componente que está encapsulado no Ogg (se é áudio ou vídeo). Para a identificação de mais
de um vídeo, foi desenvolvida uma técnica utilizando uma flag chamada “firstVideoSinked”,
que identifica se o primeiro vídeo foi associado. Assim que o primeiro vídeo for identificado,
as variáveis respectivas são associadas e a flag é marcada como verdadeira. Na próxima
iteração do laço, esta flag é testada, e se o primeiro vídeo já estiver associado, o segundo
vídeo será associado com suas respectivas variáveis.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
100
Outra alteração importante foi feita no componente interno do Cortado que desenha os
vídeos no applet Java. Com a definição de uma imagem de “background”, e com duas
instâncias do componente que desenha os vídeos rodando, o Cortado apresentava um efeito de
flickering1, pois a imagem do fundo era sobreposta aos vídeos. Para resolver este problema, o
componente que desenha os vídeos foi alterado para instanciar as variáveis que controlam a
exibição no applet apenas uma vez (através de variáveis estáticas) e utilizar a técnica de
double buffering2 para desenhar os vídeos.
Diante destas alterações, o Cortado tornase apto a exibir os streamings gerados pelos
estágios e cenários já definidos neste trabalho. Assim, a solução proposta tornase completa,
contemplando todas as fases do processo de streaming.
1 flickering – Instabilidade na tela que faz ela ou parte dela piscar2 double buffering – Técnica utilizada para reduzir ou remover problemas de visualização (como o Flickering)
no proceso de desenho da tela.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
7 ANÁLISE DA IMPLEMENTAÇÃO
Neste capítulo é realizada uma análise da solução proposta por este trabalho, com base
nos quatro estágios do streaming: captura, codificação, distribuição e visualização.
7.1 Captura e codificação
A seguir são descritos e exemplificados diversos testes de captura e codificação
realizados para validar a solução implementada. A partir dos dados computados nos testes,
são apresentadas análises comparativas entre as formas de captura, os ganhos de qualidade, o
uso de largura de banda e o uso de recursos de processamento.
Para a realização dos testes foi utilizado como computador produtor uma máquina com
processador Intel Core 2 Duo T5500 operando a 1.66GHz, com cache L2 de 2MB, FSB de
667MHz e com 1GB de memória RAM.
Nos testes realizados, notouse que o uso de slides com ou sem transição praticamente
não interfere nos resultados. Como as transições de um slide para outro são extremamente
rápidas em relação ao tempo em que cada slide fica estático, não há aumento significativo da
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
102
taxa de bits utilizando codificação VBR, não há perda de qualidade perceptível utilizandose
CBR e nem aumento significativo de processamento. Isto ocorre porque o custo da transição
em termos de largura de banda é amortizado ao longo dos quadros estáticos seguintes.
7.1.1 Cenários utilizados nos testes
Conforme pode ser visto na TABELA 5, foram criados três cenários para a realização
dos testes. Esta tabela apresenta a identificação de cada cenário, a resolução do vídeo com os
slides (denominado vídeo 1) a taxa de quadros do vídeo 1 medida em quadros por segundo
(qps), a resolução e taxa de quadros para o vídeo da câmera (denominado vídeo 2) a
quantidade de amostras por segundo do áudio medida em kHz bem como o número de canais
de áudio. Estes cenários foram projetados pensandose em atender três necessidades distintas.
O primeiro cenário foi projetado para a utilização com slides sem efeitos de transição
(em função da taxa de quadros por segundo ser muito baixa), que tenham fontes com tamanho
acima de 18, com o vídeo da câmera em baixa resolução e com áudio apenas para voz
humana. O objetivo deste cenário é atingir taxas de bits muito baixas. É o cenário ideal
TABELA 5 – Cenários utilizados nos testes
Cen.Resolução do vídeo 1
Taxa de quadros do
vídeo 1 (qps)
Resolução do vídeo 2
Taxa de quadros do
vídeo 2 (qps)
Taxa de amostras do áudio (kHz)
Número de canais de
áudio
I 640x480 1 176x144 6,25 22,05 1
II 640x480 3 320x240 6,25 44,1 2
III 800x600 5 320x240 12,5 48 2
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
103
quando se tem uma largura de banda limitada e a necessidade de atendimento de um grande
número de clientes.
O segundo cenário foi projeto para a utilização com slides com ou sem efeitos de
transição, que tenham fonte com tamanho acima de 12, com o vídeo da câmera em boa
resolução e qualquer tipo de áudio. O objetivo deste cenário é atingir baixas e intermediárias
taxas de bits, aliado a boas qualidades. É o cenário mais flexível e que está mais de acordo
com o que foi proposto por este trabalho.
O último cenário foi projetado para a utilização de qualquer aplicação, como
apresentação de slides, treinamento ou demonstração de algum software, com qualquer
tamanho de fonte e áudio em qualidade mais alta. O objetivo deste cenário é produzir
resultados de alta qualidade sem se preocupar com largura de banda. É o cenário ideal para
utilização em redes internas.
Para a validação destes cenários, foi feita uma série de testes aplicando cada um destes
às três formas de captura de slides apresentadas.
7.1.2 Testes com a captura da saída de vídeo do computador
Para os testes da forma de captura através da saída de vídeo do computador, foi
utilizado um conversor de VGA para SVideo e a captura foi feita através de uma placa de
captura de vídeo analógico. Para esta forma de captura, o cenário III foi descartado, uma vez
que a resolução de slides deste cenário é superior à resolução equivalente do sinal SVideo.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
104
A TABELA 6 apresenta todos os testes utilizando codificação VBR e CBR que foram
realizados para esta forma de captura. Cada linha desta tabela representa um teste de dez
minutos com uma apresentação de dez slides, com uma transição a cada minuto.
TABELA 6 – Testes com forma analógica de captura
Cen. Tipo Vídeo 1 Vídeo 2 ÁudioUso de
processamento (%)
Taxa de bitstotal
(kbps)
PSNR Vídeo 1 (dB)
I VBR quality=8 quality=4 quality=0.1 23 59 19,93
I VBR quality=16 quality=8 quality=0.1 22 66 21,14
I CBR bitrate=24 bitrate=12 bitrate=12 26 48 19,97
I CBR bitrate=48 bitrate=24 bitrate=16 25 88 22,06
II VBR quality=8 quality=4 quality=0.1 32 123 18,69
II VBR quality=16 quality=8 quality=0.1 33 124 21,11
II VBR quality=32 quality=16 quality=0.2 35 162 23,34
II VBR quality=63 quality=32 quality=0.2 36 356 25,71
II CBR bitrate=24 bitrate=16 bitrate=16 33 56 19,96
II CBR bitrate=48 bitrate=32 bitrate=24 33 104 21,77
II CBR bitrate=96 bitrate=64 bitrate=32 35 192 22,91
II CBR bitrate=192 bitrate=128 bitrate=32 33 352 23,56
As cinco primeiras colunas da tabela detalham os cenários apresentados na TABELA
5, o tipo de codificação (constante ou variável) e a variação dos parâmetros de codificação
dois dois canais de vídeo e do canal de áudio.
As últimas três colunas da tabela apresentam os resultados obtidos em cada um dos
testes. A primeira destas três apresenta o processamento médio medido ao longo dos dez
minutos de cada teste, que foi obtido medindose a carga total de processamento do sistema
com o mínimo de recursos necessários sendo executados pelo sistema operacional. A segunda
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
105
apresenta a taxa de bits total do sistema, no caso de VBR calculado como taxa de bits média e
no caso de CBR somandose as taxas de bits dos dois vídeos e do áudio. A última coluna
representa a medição do PSNR (Peak SignaltoNoise Ratio) do vídeo dos slides.
A forma mais tradicional de medição da qualidade de vídeo é o cálculo do PSNR, a
Razão entre Pico de Sinal e Ruído. O PSNR é geralmente calculado sobre as amostras de
luminância e é dado em decibéis. Quanto maior ele for, melhor a qualidade.
O PSNR é medido em decibéis a partir da seguinte expressão (para amostras de n
bits):
O MSE (Mean Squared Error) é o Erro Médio Quadrático e corresponde à média do
quadrado das diferenças entre cada amostra original e a amostra correspondente após o
processo de codificação/decodificação.
A medição do PSNR foi feita através do pacote Netpbm1 levandose em conta o sinal
de luminância de um slide estático. Para fazer esta medição, primeiramente foi gravado um
vídeo bruto, ou seja, sem compactação nenhuma. A partir deste vídeo foi extraído no formato
PPM (Portable PixMap)2 um slide com bastante detalhes, como uma tabela e diversas frases
com fontes em tamanho 14. Posteriormente, para cada teste que era realizado, o mesmo slide
era extraído já codificado para Theora no mesmo formato e comparado com o slide original.
A decisão de apresentar apenas o PSNR do vídeo dos slides devese ao fato deste trabalho
estar focado na apresentação de slides, uma vez que o vídeo de uma câmera é um problema
1 Netpbm – Pacote livre de mais de 220 ferramentas para manipulação de imagens em mais de 80 formatos.2 PPM – Formato de arquivo de imagem do Netpbm que utiliza 24 bits por pixel.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
106
bem resolvido pelas ferramentas livres existentes e que pode sofrer significativa influência
dos movimentos e das cores presentes.
7.1.3 Testes com a captura via RFB
Para possibilitar uma análise comparativa, os mesmos testes realizados com a captura
analógica foram feitos com a captura RFB. Neste caso, o cenário III foi incluído nos testes,
uma vez que a resolução especificada pelo cenário é atendida pelo protocolo RFB.
Estes testes são apresentados na TABELA 7.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
107
TABELA 7 – Testes com captura via RFB
Cen. Tipo Vídeo 1 Vídeo 2 ÁudioUso de
processamento (%)
Taxa de bitstotal
(kbps)
PSNR Vídeo 1 (dB)
I VBR quality=8 quality=4 quality=0.1 24 55 27,37
I VBR quality=16 quality=8 quality=0.1 24 58 29,95
I CBR bitrate=24 bitrate=12 bitrate=12 26 48 27,56
I CBR bitrate=48 bitrate=24 bitrate=16 27 88 31,06
II VBR quality=8 quality=4 quality=0.1 33 105 29,49
II VBR quality=16 quality=8 quality=0.1 32 111 30,12
II VBR quality=32 quality=16 quality=0.2 34 135 34,60
II VBR quality=63 quality=32 quality=0.2 35 182 47,76
II CBR bitrate=24 bitrate=16 bitrate=16 32 56 30,66
II CBR bitrate=48 bitrate=32 bitrate=24 32 104 36,47
II CBR bitrate=96 bitrate=64 bitrate=32 35 192 38,22
II CBR bitrate=192 bitrate=128 bitrate=32 34 352 39,04
III VBR quality=32 quality=32 quality=0.3 42 257 35,42
III VBR quality=63 quality=63 quality=0.3 41 982 48,32
III CBR bitrate=128 bitrate=128 bitrate=64 40 320 39,27
III CBR bitrate=256 bitrate=256 bitrate=64 40 576 40,29
7.1.4 Testes com a captura via chamadas à Xlib
Os mesmos testes realizados com a captura via RFB foram feitos com a captura via
Xlib, e são apresentados na TABELA 8.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
108
TABELA 8 – Testes com captura via Xlib
Cen. Tipo Vídeo 1 Vídeo 2 ÁudioUso de
processamento (%)
Taxa de bits total
(kbps)
PSNR Vídeo 1 (dB)
I VBR quality=8 quality=4 quality=0.1 27 54 29,27
I VBR quality=16 quality=8 quality=0.1 28 64 31,15
I CBR bitrate=24 bitrate=12 bitrate=12 27 48 27,22
I CBR bitrate=48 bitrate=24 bitrate=16 27 88 28,43
II VBR quality=8 quality=4 quality=0.1 38 118 26,99
II VBR quality=16 quality=8 quality=0.1 38 132 29,16
II VBR quality=32 quality=16 quality=0.2 37 152 33,20
II VBR quality=63 quality=32 quality=0.2 40 218 46,19
II CBR bitrate=24 bitrate=16 bitrate=16 37 56 25,89
II CBR bitrate=48 bitrate=32 bitrate=24 39 104 27,38
II CBR bitrate=96 bitrate=64 bitrate=32 37 192 29,82
II CBR bitrate=192 bitrate=128 bitrate=32 40 352 31,74
III VBR quality=32 quality=32 quality=0.3 60 342 36,56
III VBR quality=63 quality=63 quality=0.3 63 1.142 46,78
III CBR bitrate=128 bitrate=128 bitrate=64 56 320 38,31
III CBR bitrate=256 bitrate=256 bitrate=64 57 576 40,11
7.1.5 Análises comparativas
A partir dos dados apresentados nas TABELAS 6, 7 e 8, foi possível fazer uma série
de análises. Estas análises foram feitas com base no cenário II, por terem sido feitas mais
variações de parâmetros de entrada neste cenário e também pelo fato de este cenário ser o
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
109
mais afinado com os objetivos deste trabalho, uma vez que conseguese obter PSNRs acima
de 47dB com taxas de bits próximas de 180kbps.
Para ilustração dos resultados em forma de gráficos, a captura dos slides via saída de
vídeo do computador foi nomeada de Analógico, a captura via RFB foi nomeada de RFB e a
captura via chamadas ao modo gráfico do GNU/Linux através da Xlib foi nomeada de Xlib.
Na FIGURA 24 é apresentada uma análise comparativa da qualidade do vídeo dos
slides entre as três formas de captura com base em seu PSNR utilizando codificação VBR e
CBR. Como pode ser notado nos dois gráficos, a captura via RFB é a que apresenta melhor
qualidade e a captura analógica é a que apresenta pior qualidade, justamente devido ao fato
desta última adquirir ruído ao passar por um canal analógico, fato que não ocorreria caso
fosse utilizado um conversor de VGA para FireWire. Quando se usa VBR, podese notar que
nas capturas digitais, ou seja, RFB e Xlib, o Theora consegue gerar um vídeo com PSNRs
mais altos, ou seja, com “quality” a partir de 30 o codec apresenta um PSNR superior a 32dB.
Essa relação se modifica um pouco utilizandose CBR, pois neste a captura via RFB se
destaca, e a partir de 48kbps já apresenta um PSNR próximo a 38dB.
FIGURA 24 – Comparação do PSNR do vídeo dos slides entre as três formas de captura
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
110
Na FIGURA 25 é apresentada uma análise comparativa de qualidade entre a
codificação com taxa de bits constante e variável (taxa de bits média). A partir desta análise é
possível notar que, quando se trata de qualidade, o Theora inicialmente é mais eficiente
utilizando codificação CBR e a partir de um certo ponto passa a se tornar mais eficiente
utilizandose VBR. Esta relação fica clara nas três formas de captura, mas é mais evidenciada
na captura RFB. Com base no gráfico da captura RFB, podese afirmar que para taxas de bits
abaixo de 150kbps devese usar CBR, e para taxas de bits acima disso, VBR. Cabe ressaltar
que estes testes são bem específicos, com vídeos com pouco movimento, e portanto, não
podem ser comparados a outros testes realizados com este ou com outros codecs.
FIGURA 25 – Comparação do PSNR do vídeo dos slides entre as três formas de captura com base na taxa de bits.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
111
Na FIGURA 26 é apresentada uma análise comparativa entre as três formas de captura
da evolução da taxa de bits média com base no incremento da qualidade quando se utiliza
codificação VBR. Como pode ser visto, a forma de captura mais eficiente é a captura via
RFB, pois é a forma de apresenta uma menor taxa de bits média de acordo com o incremento
do parâmetro “quality”. A partir deste gráfico podese notar também que o Theora é muito
eficiente quando se define o parâmetro “quality” superior a 32. Utilizandose a máxima
qualidade na captura via RFB obtémse uma taxa de bits média do sistema inferior a 200
kbps.
FIGURA 26– Comparação da taxa de bits do vídeo dos slides entre as três formas de captura com base na codificação VBR
Na FIGURA 27 é apresentada a análise comparativa entre as três formas de captura do
uso de processamento utilizandose VBR e CBR. Como pode ser visto, as formas de captura
Analógica e via RFB utilizam praticamente a mesma quantidade de processamento, enquanto
a captura via Xlib requer um pouco mais de recursos. Esta relação é a mesma para VBR e
para CBR. Podese notar também que a quantidade de processamento necessária para cada
forma de captura é praticamente a mesma conforme se varia os parâmetros de qualidade e
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
112
taxa de bits. Ainda é possível perceber que as codificações VBR e CBR também utilizam
praticamente a mesma quantidade de processamento.
FIGURA 27– Comparação do uso de processamento entre as três formas de captura usando VBR e CBR
Fazendose uma análise geral, a captura via RFB é a que apresenta a melhor relação
custo x benefício. Durante todos os testes esta foi a forma de captura que apresentou a melhor
qualidade, e junto com a captura analógica, a que menos utilizou processamento.
Diante disso, podese apontar a qualidade como uma grande vantagem da captura via
RFB. Entre suas desvantagens podese citar a dependência de uma ferramenta instalada no
cliente (VNC) e a interligação de rede do computador apresentador de slides e do computador
produtor.
Sobre a forma de captura via Xlib, também é possível apontar a qualidade como uma
vantagem. Outra vantagem é a praticidade, pois a apresentação de slides, a captura e a
codificação acontecem no mesmo computador. Entre suas desvantagens, podese apontar a
dependência de um sistema operacional específico e maior demanda de processamento.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
113
Sobre a captura analógica, podese apontar como vantagem a não interferência no
ambiente do cliente, uma vez que a captura é feita diretamente no hardware. Como
desvantagem podese apontar a qualidade inferior às outras formas de captura. Vale salientar
que se fosse utilizado um conversor de VGA para FireWire, esta diferença de qualidade para
as outras formas de captura seria minimizada, e ainda haveria a possibilidade de utilizarse
resoluções maiores para os slides.
A TABELA 8 apresenta um comparativo geral das vantagens e das desvantagens de
cada uma das três formas de captura dos slides.
TABELA 8 – Comparativo entre formas de captura de slidesQuestão Analógica RFB Xlib
Interferência no ambiente do cliente nenhuma média alta
Dependência de sistema operacional não não sim
Dependência de conexão de rede entre apresentação de slides e produção
não sim
Qualidade baixa/média alta alta
Bitrate médio (VBR) alto baixo médio
Consumo de processamento médio médio médio/alto
7.2 Distribuição
Conforme já foi dito, a distribuição do streaming é um problema bem resolvido pelas
ferramentas livres já existentes e não foi o foco deste trabalho.
Cabe salientar aqui que uma parte muito importante do estágio de distribuição está
atrelada à forma como os dados são gerados no estágio de codificação. É fundamental
conhecer os limites de distribuição disponíveis bem como o número de clientes que devem ser
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
114
atendidos para que os parâmetros de taxa de bits (CBR) ou qualidade (VBR) sejam definidos
corretamente de forma a maximizar a relação qualidade x taxa de bits.
7.3 Visualização
Outra parte importante deste trabalho foi adaptar o applet Cortado para exibição de
dois canais de vídeo.
Para a validação do Cortado modificado, este foi utilizado para a visualização de todos
os testes realizados na etapa de captura e codificação. Além disso, foram feitos testes de
compatibilidade com o Java 5 e Java 6, em GNU/Linux e em Microsoft Windows XP. Em
todos os testes e ambientes a ferramenta se portou de igual forma. A partir disso podese
concluir que o estágio de visualização atingiu seu objetivo, pois o Cortado pode ser visto
como uma solução transparente e flexível, uma vez que é executada da mesma forma em
vários sistemas operacionais, bastando estar embutido em um navegador Web.
Cabe ressaltar aqui uma limitação importante do Ogg e conseqüentemente do Cortado.
O container Ogg não tem em seu cabeçalho inicial informações sobre a duração do
streaming. Como o Cortado precisa saber a duração do streaming para ativar uma barra de
posicionamento para tornar possível avançar e recuar no streaming sobdemanda, essa
informação deve ser passada ao applet manualmente através do parâmetro “duration”, via
HTML ou Javascript. Existem ferramentas que conseguem obter a duração de um streaming
Ogg, como o “oggzinfo”, mas para isso precisam ter acesso a todo o conteúdo do arquivo, fato
que não ocorre no streaming sobdemanda.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
8 CONCLUSÃO
Este trabalho teve por objetivo apresentar uma solução baseada em tecnologias livres
para sincronização de slides com um streaming de vídeo e áudio, aliandose boas qualidades a
baixas taxas de bits.
A meta do trabalho foi atingida, uma vez que provouse ser possível transmitir vídeo e
áudio juntamente com slides com uma taxa de bits baixa e uma boa qualidade. Um exemplo
forte disso é a possibilidade de distribuir slides sem movimentação a 3 quadros por segundo
com PSNR superior a 47dB utilizandose uma taxa de bits média de todo o sistema em torno
de 180kbps.
A partir dos cenários montados e dos resultados apresentados, podese concluir que o
uso da solução apresentada por este trabalho não fica restrita a slides, uma vez que a captura
do ambiente de trabalho é feita em tempo real. A partir disto, é possível, por exemplo, utilizar
a solução para treinamentos virtuais e demonstração de softwares.
Em termos gerais, a melhor forma de capturar os slides é a captura por RFB, pois
conseguese obter PSNRs mais altos com taxas de bits mais baixas, ou, em outras palavras,
apresenta uma melhor relação custo x benefício. Vale ressaltar que isso não vale como regra,
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
116
uma vez que esta forma de captura dos slides pode não atender a alguns situações, que por sua
vez poderiam ser melhor atendidas por uma das outras duas formas de captura.
Cabe destacar como relevantes as seguintes contribuições:
● Pesquisa detalhada de tecnologias livres disponíveis para streaming.
● Validação de ferramentas e tecnologias livres como robustas e maduras para os
mais diversos usos.
● Alterações de ferramentas livres existentes para atingir o objetivo, resultando
em contribuições para os referidos projetos.
● Montagem de uma solução totalmente livre para sincronização de slides com
streaming de vídeo e áudio, ideal para utilização em ensino à distância.
● Testes e avaliações da solução com simulação de cenários reais e
estabelecimento de orientações gerais em relação às configurações mais adequadas
para cada caso.
Como continuidade deste projeto são propostos os seguintes estudos futuros:
● Incorporar novos recursos à solução, como chat livre e moderado, quadro
branco compartilhado e vídeo e áudio multidirecional, para montagem de uma
ferramenta mais completa para ensino à distância, equivalente às soluções
proprietárias existentes.
● Testar e avaliar a forma de captura da saída de vídeo do computador utilizando
um conversor de VGA para FireWire.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
117
● Adaptar e expandir o suporte de outras ferramentas para exibição do formato
Ogg com dois canais de vídeo.
● Adaptar e expandir o suporte a outros codecs de vídeo e de áudio, tanto livres
quanto proprietários, que sejam suportados pelo Gstreamer e desenvolver ou adaptar
um reprodutor multimídia para estes formatos.
● Estudar a possibilidade de redução da da taxa de bits global utilizando um
codec de áudio específico para voz.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
REFERÊNCIAS
ADOBE SYSTEMS INCORPORATED. Adobe solutions for the virtual classroom: Opening the campus, extending the reach of the classroom. San Jose: 2006.
AUSTERBERRY, David. The Technology of Video & Audio Streaming. 2. ed. Oxford: Focal Press, 2004.
BHATTACHARYA, Rishi. DSP video processing via opensourceAPIs. Nova Iorque: EETIMES, 2006. Disponível em <http://www.eetimes.com/news/design/showArticle.jhtml?articleID=193401461>. Acesso em: 05 nov. 2007.
DO AMARAL, Sergio Ferreira; BARATTI, Luciana Ozello; BATACA, Daniel Moutinho; FRANCO, João Henrique de Augustinis; RIOS, José Manuel Martin; LAMAS, Amilton da Costa. Serviço de apoio a distância ao professor em sala de aula pela TV digital interativa . Campinas, 2004.
GRIFFIN, Robert E.; PARRISH, Dana; REIGH, Michael. Using Virtual Classroom Tools In Distance Learning: Can The Classroom Be Recreated At A Distance? Loretto: 2005.
JACK, Keith. Video Demystified: a handbook for the digital engineer. 3. ed. Eagle Rock: LLH Technology Publishing, 2001.
KLASS, Brian. Streaming Media in Higher Education: Possibilities and Pitfalls. Campus Technology. Disponível em <http://campustechnology.com/articles/38707/>. Acesso em: 12 jun. 2007.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
119
LIRA, Marcelo. Apresentando o Gstreamer. Pernambuco: 2006. Disponível em <http://www.cin.ufpe.br/~cinlug/wiki/index.php/Apresentando_o_GStreamer>. Acesso em: 07 nov. 2007.
MACK, Steve. Streaming Media Bible. New York: Hungry Minds, 2002.
MANOEL, Edson Tadeu Monteiro. Codificação de vídeo h.264 – estudo de codificação mista de macroblocos . Florianópolis: 2007.
MEHLECKE, Querte Teresinha Conzi; TAROUCO, Liane Margarida Rockenbach. Ambientes de suporte para educação a distância: A mediação para aprendizagem cooperativa. Porto Alegre: CINTEDUFRGS, 2003.
MICROSOFT CORPORATION. Choosing a Microsoft Web Conferencing Solution. Redmond: 2007.
PFEIFFER, Silvia. RFC 3533: The Ogg Encapsulation Format Version 0. North Ryde: 2003. Disponível em <http://xiph.org/ogg/doc/rfc3533.txt>. Acesso em: 31 out. 2007.
STICHELE, Thomas Vander; SCHALLER, Christian Fredrik Kalager. Flumotion Manual. Barcelona: 2004. Disponível em <http://www.flumotion.net/doc/flumotion/manual/html/>. Acesso em: 10 mai 2007.
TANENBAUM, Andrew S. Redes de Computadores. 4. ed. Rio de Janeiro: Campus, 1997.
TAYMANS, Wim; BAKER, Steve; WINGO, Andy; BULTJE, Ronald S.; KOST Stefan. GStreamer Application Development Manual. Barcelona: 2007. Disponível em <http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/index.html>. Acesso em: 06 nov. 2007.
WAGNER, Ellen. Delivering on the Promise of eLearning. San Jose: 2006. Adobe Systems Inc.
WALLEIF, Linus. RFC 3534: The application/ogg Media Type. Lund: 2003. Disponível em <http://xiph.org/ogg/doc/rfc3534.txt>. Acessso em: 31 out. 2007.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
120
WINKLER, Stefan. Digital Video Quality: vision models and metrics. West Succesx: Wiley, 2005.
XIPH.ORG FOUNDATION. Libogg API Overview. Eugene: 2000. Disponível em <http://xiph.org/ogg/doc/libogg/overview.html>. Acesso em: 31 out. 2007.
XIPH.ORG FOUNDATION. Ogg logical and physical bitstream overview. Eugene: 2005. Disponível em <http://xiph.org/ogg/doc/oggstream.html>. Acesso em: 31 out. 2007.
XIPH.ORG FOUNDATION. Ogg logical bitstream framing. Eugene: 2005. Disponível em <http://xiph.org/ogg/doc/framing.html>. Acesso em: 31 out. 2007.
XIPH.ORG FOUNDATION. Ogg Vorbis: Fidelity measurement and terminology discussion. Eugene: 2005. Disponível em <http://xiph.org/vorbis/doc/vorbisfidelity.html>. Acceso em: 31 out. 2007.
XIPH.ORG FOUNDATION. Page Multiplexing and Ordering in a Physical Ogg Stream. Eugene: 2005. Disponível em <http://xiph.org/ogg/doc/oggmultiplex.html>. Acesso em: 31 out. 2007.
XIPH.ORG FOUNDATION. Theora Especification. Eugene: 2007. Disponível em <http://theora.org/doc/Theora.pdf>. Acceso em: 31 out. 2007.
XIPH.ORG FOUNDATION. Theora FAQ. Eugene: 2007. Disponível em <http://theora.org/faq/>. Acceso em: 31 out. 2007.
XIPH.ORG FOUNDATION. Vorbis I specification. Eugene: 2007. Disponível em <http://xiph.org/vorbis/doc/Vorbis_I_spec.html>. Acceso em: 31 out. 2007.
ZHAO, Yanping; EAGER Derek L.; VERNON, Mary K. Network Bandwidth Requirements for Scalable OnDemand Streaming. IEEE/ACM TRANSACTIONS ON NETWORKING: 2007.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICES
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE APÊNDICES
APÊNDICE 1 Patch gerado pelo CVS para o componente “librfb” do Gstreamer para tornar
possível transformar uma taxa de quadros variável em fixa...................................................123
APÊNDICE 2 – Patch gerado pelo SVN para o applet Cortado para exibição de dois canais de
vídeo e definição de imagem de fundo...................................................................................126
APÊNDICE 3 Configuração do Flumotion para captura de slides via RFB, codificação
VBR, distribuição via rede pelo Flumotion e armazenamento em disco................................136
APÊNDICE 4 Configuração do Flumotion para captura de slides via modo gráfico do
GNU/Linux, codificação CBR, distribuição via Icecast e armazenamento em disco.............138
APÊNDICE 5 Pipeline do Gstreamer para captura de slides pela saída de vídeo do
computador, codificação CBR e armazenamento em disco....................................................140
APÊNDICE 6 Pipeline do Gstreamer para captura de slides via RFB, codificação VBR e
distribuição via Icecast............................................................................................................141
APÊNDICE 7 Pipeline do Gstreamer para captura de slides via chamadas ao modo gráfico
do GNU/Linux, codificação VBR, armazenamento em disco e distribuição via Icecast.......142
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE 1 Patch gerado pelo CVS para o componente “librfb” do Gstreamer
para tornar possível transformar uma taxa de quadros variável em fixa.
Index: gstrfbsrc.c =================================================================== RCS file: /cvs/gstreamer/gst-plugins-bad/gst/librfb/gstrfbsrc.c,v retrieving revision 1.19 diff -u -r1.19 gstrfbsrc.c --- gstrfbsrc.c 31 Oct 2007 14:09:25 -0000 1.19 +++ gstrfbsrc.c 21 Nov 2007 23:44:43 -0000 @@ -43,6 +43,8 @@ ARG_WIDTH, ARG_HEIGHT, ARG_INCREMENTAL, + ARG_KEEP_ALIVE, + ARG_KEEP_ALIVE_RATE, }; GST_DEBUG_CATEGORY_STATIC (rfbsrc_debug); @@ -85,6 +87,8 @@ static GstFlowReturn gst_rfb_src_create (GstPushSrc * psrc, GstBuffer ** outbuf); +static void gst_rfb_src_keep_alive (GstBaseSrc * psrc); + GST_BOILERPLATE (GstRfbSrc, gst_rfb_src, GstPushSrc, GST_TYPE_PUSH_SRC); static void @@ -140,6 +144,14 @@ g_object_class_install_property (gobject_class, ARG_INCREMENTAL, g_param_spec_boolean ("incremental", "Incremental updates", "Incremental updates", TRUE, G_PARAM_READWRITE)); + g_object_class_install_property (gobject_class, ARG_KEEP_ALIVE, + g_param_spec_boolean ("keep-alive", "Periodic actualization", + "Generates periodic actualizations even if there are no desktop changes, thus keeping the stream alive", + FALSE, G_PARAM_READWRITE)); + g_object_class_install_property (gobject_class, ARG_KEEP_ALIVE_RATE, + g_param_spec_float ("keep-alive-rate", "Keep alive rate", + "Keep alive rate", 0.0, 120.0, 3.0, G_PARAM_READWRITE)); + gstbasesrc_class->start = GST_DEBUG_FUNCPTR (gst_rfb_src_start); gstbasesrc_class->stop = GST_DEBUG_FUNCPTR (gst_rfb_src_stop); @@ -165,6 +177,9 @@ src->incremental_update = TRUE; + src->keep_alive = FALSE; + src->keep_alive_rate = 3; + src->decoder = rfb_decoder_new (); } @@ -258,6 +273,12 @@ case ARG_INCREMENTAL: src->incremental_update = g_value_get_boolean (value); break;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
124
+ case ARG_KEEP_ALIVE: + src->keep_alive = g_value_get_boolean (value); + break; + case ARG_KEEP_ALIVE_RATE: + src->keep_alive_rate = g_value_get_float (value); + break; default: break; } @@ -297,6 +318,12 @@ case ARG_INCREMENTAL: g_value_set_boolean (value, src->incremental_update); break; + case ARG_KEEP_ALIVE: + g_value_set_boolean (value, src->keep_alive); + break; + case ARG_KEEP_ALIVE_RATE: + g_value_set_float (value, src->keep_alive_rate); + break; default: G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec); break; @@ -349,6 +376,12 @@ gst_pad_set_caps (GST_BASE_SRC_PAD (bsrc), caps); gst_caps_unref (caps); + if ( src->keep_alive ) + { + g_thread_create((GThreadFunc) gst_rfb_src_keep_alive, + bsrc , TRUE, NULL); + } + return TRUE; } @@ -401,6 +434,9 @@ memcpy (GST_BUFFER_DATA (*outbuf), decoder->frame, newsize); GST_BUFFER_SIZE (*outbuf) = newsize; + GST_BUFFER_TIMESTAMP (*outbuf) = + gst_clock_get_time (GST_ELEMENT_CLOCK (src)) - + GST_ELEMENT_CAST (src)->base_time; return GST_FLOW_OK; } @@ -461,6 +497,19 @@ GST_TYPE_RFB_SRC); } +static void +gst_rfb_src_keep_alive (GstBaseSrc * bsrc) +{ + GstRfbSrc *src = GST_RFB_SRC (bsrc); + RfbDecoder *decoder = src->decoder; + + while (1) + { + rfb_decoder_send_update_request (decoder, FALSE, 0, 0, 16, 16);
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
125
+ g_usleep(src->keep_alive_rate * G_USEC_PER_SEC); + } +} + GST_PLUGIN_DEFINE (GST_VERSION_MAJOR, GST_VERSION_MINOR, "rfbsrc", Index: gstrfbsrc.h =================================================================== RCS file: /cvs/gstreamer/gst-plugins-bad/gst/librfb/gstrfbsrc.h,v retrieving revision 1.4 diff -u -r1.4 gstrfbsrc.h --- gstrfbsrc.h 31 Oct 2007 14:09:25 -0000 1.4 +++ gstrfbsrc.h 21 Nov 2007 23:44:43 -0000 @@ -62,6 +62,9 @@ guint version_major; guint version_minor; + gboolean keep_alive; + gfloat keep_alive_rate; + }; GType gst_rfb_src_get_type (void);
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE 2 – Patch gerado pelo SVN para o applet Cortado para exibição de dois
canais de vídeo e definição de imagem de fundo.
Index: src/com/fluendo/player/CortadoPipeline.java =================================================================== --- src/com/fluendo/player/CortadoPipeline.java (revisão 5687) +++ src/com/fluendo/player/CortadoPipeline.java (cópia de trabalho) @@ -36,27 +36,41 @@ private int bufferLow = -1; private int bufferHigh = -1; private URL documentBase = null; + private boolean keepDimension; + private Point coordinate0; + private Point coordinate1; + private int videoChannels; + private String background; + private int videosSinked = 0; private Element httpsrc; private Element buffer; private Element demux; - private Element videodec; + private Element videodec0, videodec1; private Element audiodec; - private Element videosink; + private Element videosink0, videosink1; private Element audiosink; - private Element v_queue, a_queue; - private Pad asinkpad, vsinkpad; - private Pad apad, vpad; + private Element v_queue0, v_queue1, a_queue; + private Pad asinkpad, vsinkpad0, vsinkpad1; + private Pad apad, vpad0, vpad1; public boolean usingJavaX = false; private boolean setupVideoDec (String name) { - videodec = ElementFactory.makeByName(name, "videodec"); - if (videodec == null) { + videodec0 = ElementFactory.makeByName(name, "videodec0"); + if (videodec0 == null) { noSuchElement (name); return false; } - add(videodec); + add(videodec0); + + videodec1 = ElementFactory.makeByName(name, "videodec1"); + if (videodec1 == null) { + noSuchElement (name); + return false; + } + add(videodec1); + return true; } @@ -101,67 +115,102 @@
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
127
a_queue.setState (PAUSE); } else if (enableVideo && mime.equals("video/x-theora")) { - v_queue = ElementFactory.makeByName("queue", "v_queue"); - if (v_queue == null) { - noSuchElement ("queue"); - return; + if ( videosSinked == 0 ) { + v_queue0 = ElementFactory.makeByName("queue", "v_queue0"); + if (v_queue0 == null) { + noSuchElement ("queue"); + return; + } + + if (!setupVideoDec ("theoradec")) + return; + + add(v_queue0); + + pad.link(v_queue0.getPad("sink")); + v_queue0.getPad("src").link(videodec0.getPad("sink")); + if (!videodec0.getPad("src").link(vsinkpad0)) { + postMessage (Message.newError (this, "videosink already linked")); + return; + } + + vpad0 = pad; + + videodec0.setState (PAUSE); + v_queue0.setState (PAUSE); + videosSinked++; + } - - if (!setupVideoDec ("theoradec")) + else { + v_queue1 = ElementFactory.makeByName("queue", "v_queue1"); + if (v_queue1 == null) { + noSuchElement ("queue"); return; + } + + if (!setupVideoDec ("theoradec")) + return; + + add(v_queue1); - add(v_queue); + pad.link(v_queue1.getPad("sink")); + v_queue1.getPad("src").link(videodec1.getPad("sink")); + if (!videodec1.getPad("src").link(vsinkpad1)) { + postMessage (Message.newError (this, "videosink already linked")); + return; + } + + vpad1 = pad;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
128
+ + videodec1.setState (PAUSE); + v_queue1.setState (PAUSE); + videosSinked++; - pad.link(v_queue.getPad("sink")); - v_queue.getPad("src").link(videodec.getPad("sink")); - if (!videodec.getPad("src").link(vsinkpad)) { - postMessage (Message.newError (this, "videosink already linked")); - return; } - - vpad = pad; - - videodec.setState (PAUSE); - v_queue.setState (PAUSE); } else if (enableVideo && mime.equals("image/jpeg")) { if (!setupVideoDec ("jpegdec")) { return; } - videodec.setProperty ("component", component); + videodec0.setProperty ("component", component); - pad.link(videodec.getPad("sink")); - if (!videodec.getPad("src").link(vsinkpad)) { + pad.link(videodec0.getPad("sink")); + if (!videodec0.getPad("src").link(vsinkpad0)) { postMessage (Message.newError (this, "videosink already linked")); return; } - videodec.setState (PAUSE); + videodec0.setState (PAUSE); } else if (enableVideo && mime.equals("video/x-smoke")) { if (!setupVideoDec ("smokedec")) { return; } - videodec.setProperty ("component", component); + videodec0.setProperty ("component", component); - pad.link(videodec.getPad("sink")); - if (!videodec.getPad("src").link(vsinkpad)) { + pad.link(videodec0.getPad("sink")); + if (!videodec0.getPad("src").link(vsinkpad0)) { postMessage (Message.newError (this, "videosink already linked")); return; } - vpad = pad; + vpad0 = pad; - videodec.setState (PAUSE); + videodec0.setState (PAUSE); } } public void padRemoved(Pad pad) {
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
129
pad.unlink(); - if (pad == vpad) { + if (pad == vpad0) { Debug.log(Debug.INFO, "video pad removed "+pad); - vsinkpad.unlink(); - vpad = null; + vsinkpad0.unlink(); + vpad0 = null; } + if (pad == vpad1) { + Debug.log(Debug.INFO, "video pad removed "+pad); + vsinkpad1.unlink(); + vpad1 = null; + } else if (pad == apad) { Debug.log(Debug.INFO, "audio pad removed "+pad); asinkpad.unlink(); @@ -181,11 +230,11 @@ audiosink = null; changed = true; } - if (vpad == null && enableVideo) { + if (vpad0 == null && enableVideo) { Debug.log(Debug.INFO, "file has no video, remove videosink"); - videosink.setState(STOP); - remove (videosink); - videosink = null; + videosink0.setState(STOP); + remove (videosink0); + videosink0 = null; changed = true; } if (changed) @@ -261,6 +310,41 @@ return bufferHigh; } + public void setKeepDimension(boolean dimension) { + keepDimension = dimension; + } + public boolean getKeepDimension() { + return keepDimension; + } + + public void setCoordinate0(Point p) { + coordinate0 = p; + } + public Point getCoordinate0() { + return coordinate0; + } + + public void setCoordinate1(Point p) { + coordinate1 = p; + } + public Point getCoordinate1() { + return coordinate1; + } +
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
130
+ public void setVideoChannels(int vcs) { + videoChannels = vcs; + } + public int getVideoChannels() { + return videoChannels; + } + + public void setBackground(String back) { + background = back; + } + public String getBackground() { + return background; + } + public boolean buildOgg() { demux = ElementFactory.makeByName("oggdemux", "demux"); @@ -391,14 +475,28 @@ add(audiosink); } if (enableVideo) { - videosink = ElementFactory.makeByName("videosink", "videosink"); - if (videosink == null) { + videosink0 = ElementFactory.makeByName("videosink", "videosink0"); + if (videosink0 == null) { noSuchElement ("videosink"); return false; } - videosink.setProperty ("component", component); - vsinkpad = videosink.getPad("sink"); - add(videosink); + videosink0.setProperty ("component", component); + videosink0.setProperty ("keepDimension", keepDimension ? "true" : "false"); + videosink0.setProperty ("coordinate", coordinate0); + videosink0.setProperty ("background", background); + vsinkpad0 = videosink0.getPad("sink"); + add(videosink0); + + videosink1 = ElementFactory.makeByName("videosink", "videosink1"); + if (videosink1 == null) { + noSuchElement ("videosink"); + return false; + } + videosink1.setProperty ("keepDimension", keepDimension ? "true" : "false"); + videosink1.setProperty ("coordinate", coordinate1); + vsinkpad1 = videosink1.getPad("sink"); + add(videosink1); + } return true; @@ -415,11 +513,16 @@ audiosink = null; asinkpad = null; } - if (videosink != null) {
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
131
- remove (videosink); - videosink = null; - vsinkpad = null; + if (videosink0 != null) { + remove (videosink0); + videosink0 = null; + vsinkpad0 = null; } + if (videosink1 != null) { + remove (videosink1); + videosink1 = null; + vsinkpad1 = null; + } if (buffer != null) { remove (buffer); buffer = null; @@ -429,18 +532,26 @@ remove (demux); demux = null; } - if (v_queue != null) { - remove (v_queue); - v_queue = null; + if (v_queue0 != null) { + remove (v_queue0); + v_queue0 = null; } + if (v_queue1 != null) { + remove (v_queue1); + v_queue1 = null; + } if (a_queue != null) { remove (a_queue); a_queue = null; } - if (videodec != null) { - remove(videodec); - videodec = null; + if (videodec0 != null) { + remove(videodec0); + videodec0 = null; } + if (videodec1 != null) { + remove(videodec1); + videodec1 = null; + } if (audiodec != null) { remove(audiodec); audiodec = null; @@ -501,4 +612,4 @@ } return result; } -} +} \ Sem nova-linha ao fim do arquivo Index: src/com/fluendo/player/Cortado.java ===================================================================
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
132
--- src/com/fluendo/player/Cortado.java (revisão 5687) +++ src/com/fluendo/player/Cortado.java (cópia de trabalho) @@ -45,6 +45,11 @@ private int bufferHigh; private int debug; private double duration; + private String background; + private boolean keepDimension; + private Point coordinate0; + private Point coordinate1; + private int videoChannels; private boolean statusRunning; private Thread statusThread; @@ -114,6 +119,16 @@ "userId for basic authentication (default null)" }, { "password", "string", "password for basic authentication (default null)" }, + { "background", "string", "URL with background image (default null)" }, + { "keepDimension", "boolean", + "Keep dimension of original video (default false)" }, + { "coordinate", "point", + "Video coordinate when keepDimension is true (default \"0,0\")" }, + { "coordinate1", "point", + "Video coordinate when keepDimension is true for second video " + + " (default \"0,0\")" }, + { "videoChannels", "int", + "Number of videos (1|2) (default 1)" }, { "debug", "int", "Debug level 0 - 4 (default = 3)" }, }; return info; } @@ -225,8 +240,16 @@ bufferHigh = getIntParam("bufferHigh", 70); debug = getIntParam("debug", 3); userId = getStringParam("userId", null); + background = getStringParam("background", null); + videoChannels = getIntParam("videoChannels", 1); password = getStringParam("password", null); + keepDimension = getBoolParam("keepDimension", false); + String[] temp = getStringParam("coordinate", "0,0").split(","); + coordinate0 = new Point(Integer.parseInt(temp[0]), Integer.parseInt(temp[1])); + temp = getStringParam("coordinate1", "0,0").split(","); + coordinate1 = new Point(Integer.parseInt(temp[0]), Integer.parseInt(temp[1])); + Debug.level = debug; Debug.log(Debug.INFO, "build info: " + configure.buildInfo); Debug.log(Debug.INFO, "revision: " + getRevision()); @@ -246,6 +269,13 @@ pipeline.setBufferSize(bufferSize);
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
133
pipeline.setBufferLow(bufferLow); pipeline.setBufferHigh(bufferHigh); + pipeline.setKeepDimension(keepDimension); + pipeline.setCoordinate0(coordinate0); + pipeline.setVideoChannels(videoChannels); + pipeline.setBackground(background); + if ( videoChannels == 2 ) { + pipeline.setCoordinate1(coordinate1); + } URL documentBase; try { Index: src/com/fluendo/plugin/VideoSink.java =================================================================== --- src/com/fluendo/plugin/VideoSink.java (revisão 5702) +++ src/com/fluendo/plugin/VideoSink.java (cópia de trabalho) @@ -22,16 +22,25 @@ import java.awt.image.*; import com.fluendo.utils.*; import com.fluendo.jst.*; +import java.net.URL; public class VideoSink extends Sink { - private Component component; + private static Component component; + private static Graphics graphics; + private static Dimension dimension; + private static Image bgImage; + private static Graphics bgGraphics; private boolean keepAspect; private boolean scale; + private boolean keepDimension; + private URL background; + private boolean setBackground = false; private Frame frame; private int width, height; private int aspectX, aspectY; + private Point coordinate = new Point(-1, -1); public VideoSink () { @@ -95,45 +104,80 @@ if (!component.isVisible()) return Pad.NOT_NEGOTIATED; - Dimension d = component.getSize(); - Graphics graphics = component.getGraphics(); + if ( dimension == null || setBackground) { + dimension = component.getSize(); + } + if ( graphics == null || setBackground) { + graphics = component.getGraphics(); + } if (keepAspect) { double src_ratio, dst_ratio;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
134
src_ratio = (double) width / height; - dst_ratio = (double) d.width / d.height; + dst_ratio = (double) dimension.width / dimension.height; - if (src_ratio > dst_ratio) { - w = d.width; - h = (int) (d.width / src_ratio); + if ( keepDimension && width <= dimension.width && height <= dimension.height ) { + w = width; + h = height; + if ( coordinate.getX() >= 0 ) { + x = (int)coordinate.getX(); + } + else { + x = (dimension.width - w) / 2; + } + if ( coordinate.getY() >= 0 ) { + y = (int)coordinate.getY(); + } + else { + y = (dimension.height - h) / 2; + } + } else if (src_ratio > dst_ratio) { + w = dimension.width; + h = (int) (dimension.width / src_ratio); x = 0; - y = (d.height - h) / 2; + y = (dimension.height - h) / 2; } else if (src_ratio < dst_ratio) { - w = (int) (d.height * src_ratio); - h = d.height; - x = (d.width - w) / 2; + w = (int) (dimension.height * src_ratio); + h = dimension.height; + x = (dimension.width - w) / 2; y = 0; } else { x = 0; y = 0; - w = d.width; - h = d.height; + w = dimension.width; + h = dimension.height; } } else if (!scale) { - w = Math.min (width, d.width); - h = Math.min (height, d.height); - x = (d.width - w) / 2; - y = (d.height - h) / 2; + w = Math.min (width, dimension.width); + h = Math.min (height, dimension.height); + x = (dimension.width - w) / 2; + y = (dimension.height - h) / 2; } else { /* draw in available area */ - w = d.width;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
135
- h = d.height; + w = dimension.width; + h = dimension.height; x = 0; y = 0; } - graphics.drawImage (image, x, y, w, h, null); + // DOUBLE BUFFER FOR BACKGROUND + // initialize buffer + if (bgImage == null || setBackground) + { + bgImage = component.createImage (dimension.width, dimension.height); + bgGraphics = bgImage.getGraphics (); + setBackground = false; + } + + if ( background != null ) { + bgGraphics.drawImage(Toolkit.getDefaultToolkit().getImage(background), 0, 0, null); + } + bgGraphics.drawImage(image, x, y, w, h, null); + + // draw image on the screen + graphics.drawImage (bgImage, 0, 0, null); + return Pad.OK; }; @@ -152,6 +196,20 @@ else if (name.equals("scale")) { scale = String.valueOf(value).equals("true"); } + else if (name.equals("keepDimension")) { + keepDimension = String.valueOf(value).equals("true"); + } + else if (name.equals("coordinate")) { + coordinate = (Point) value; + } + else if (name.equals("background")) { + String temp = String.valueOf(value); + try { + background = new URL(temp); + } + catch (Exception e) {} + setBackground = true; + } else return false;
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE 3 Configuração do Flumotion para captura de slides via RFB,
codificação VBR, distribuição via rede pelo Flumotion e armazenamento em disco.
<?xml version="1.0" ?> <planet> <flow name="default"> <component name="producer-video1" project="flumotion" type="pipeline-producer" version="0.5.0.1" worker="localhost"> <property name="pipeline"> rfbsrc host=192.168.0.180 password=SENHA keep-alive=true keep-alive-rate=0.3 ! ffmpegcolorspace ! ffvideoscale ! video/x-raw-yuv,width=640,height=480 ! videorate ! video/x-raw-yuv,framerate=3/1 </property> </component>
<component name="producer-video2" project="flumotion" type="webcam-producer" version="0.5.0.1" worker="localhost">
<property name="device">/dev/video0</property> <property name="element-factory">v4lsrc</property> <property name="format">I420</property> <property name="framerate">100/16</property> <property name="height">240</property> <property name="mime">video/x-raw-yuv</property> <property name="width">320</property> </component>
<component name="encoder-video1" project="flumotion" type="theora-encoder" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>producer-video1</feed> </eater>
<property name="quality">32</property> </component>
<component name="encoder-video2" project="flumotion" type="theora-encoder" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>producer-video2</feed> </eater>
<property name="quality">16</property> </component>
<component name="producer-audio" project="flumotion" type="soundcard-producer" version="0.5.0.1" worker="localhost">
<property name="channels">2</property> <property name="depth">16</property> <property name="device">/dev/dsp</property> <property name="rate">48000</property> <property name="source-element">osssrc</property> </component>
<component name="encoder-audio" project="flumotion" type="vorbis-encoder" version="0.5.0.1" worker="localhost">
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
137
<eater name="default"> <feed>producer-audio</feed> </eater>
<property name="quality">0.1</property> </component>
<component name="muxer-audio-video" project="flumotion" type="ogg-muxer" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>encoder-video1</feed> <feed>encoder-video2</feed> <feed>encoder-audio</feed> </eater> </component>
<component name="http-audio-video" project="flumotion" type="http-streamer" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>muxer-audio-video</feed> </eater>
<property name="burst-on-connect">True</property> <property name="client-limit">500</property> <property name="mount-point">/</property> <property name="port">8800</property> </component>
<component name="disk-audio-video" project="flumotion" type="disk-consumer" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>muxer-audio-video</feed> </eater>
<property name="directory">/tmp</property> <property name="rotate-type">time</property> <property name="start-recording">True</property> <property name="time">43200</property> </component>
</flow> </planet>
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE 4 Configuração do Flumotion para captura de slides via modo gráfico
do GNU/Linux, codificação CBR, distribuição via Icecast e armazenamento em disco.
<?xml version="1.0" ?> <planet> <flow name="default"> <component name="producer-video1" project="flumotion" type="pipeline-producer" version="0.5.0.1" worker="localhost"> <property name="pipeline"> ximagesrc use-damage=false ! video/x-raw-rgb,framerate=3/1 ! ffmpegcolorspace ! videocrop left=112 right=112 ! ffvideoscale ! video/x-raw-yuv,width=640,height=480</property> </component>
<component name="producer-video2" project="flumotion" type="webcam-producer" version="0.5.0.1" worker="localhost">
<property name="device">/dev/video0</property> <property name="element-factory">v4lsrc</property> <property name="format">I420</property> <property name="framerate">100/16</property> <property name="height">240</property> <property name="mime">video/x-raw-yuv</property> <property name="width">320</property> </component>
<component name="encoder-video1" project="flumotion" type="theora-encoder" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>producer-video1</feed> </eater>
<property name="bitrate">50</property> </component>
<component name="encoder-video2" project="flumotion" type="theora-encoder" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>producer-video2</feed> </eater>
<property name="bitrate">50</property> </component>
<component name="producer-audio" project="flumotion" type="soundcard-producer" version="0.5.0.1" worker="localhost">
<property name="channels">2</property> <property name="depth">16</property> <property name="device">/dev/dsp</property> <property name="rate">48000</property> <property name="source-element">osssrc</property> </component>
<component name="encoder-audio" project="flumotion" type="vorbis-encoder" version="0.5.0.1" worker="localhost"> <eater name="default">
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
139
<feed>producer-audio</feed> </eater>
<property name="bitrate">20480</property> </component>
<component name="muxer-audio-video" project="flumotion" type="ogg-muxer" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>encoder-video1</feed> <feed>encoder-video2</feed> <feed>encoder-audio</feed> </eater> </component>
<component name="shout2-video" project="flumotion" type="shout2-consumer" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>muxer-audio-video</feed> </eater>
<property name="ip">127.0.0.1</property> <property name="mount-point">/ead.ogg</property> <property name="password">hackme</property> <property name="port">8000</property> </component>
<component name="disk-audio-video" project="flumotion" type="disk-consumer" version="0.5.0.1" worker="localhost"> <eater name="default"> <feed>muxer-audio-video</feed> </eater>
<property name="directory">/tmp</property> <property name="rotate-type">time</property> <property name="start-recording">True</property> <property name="time">43200</property> </component>
</flow> </planet>
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE 5 Pipeline do Gstreamer para captura de slides pela saída de vídeo do
computador, codificação CBR e armazenamento em disco.
gst-launch \ osssrc ! \ audio/x-raw-int,rate=\(int\)44100,depth=16,channels=2 ! \ audioresample ! \ audioconvert ! \ capsfilter ! audio/x-raw-float,rate=\(int\)12000 ! \ vorbisenc bitrate=20480 ! \ queue ! mux::file. \ v4l2src device=/dev/video1 ! \ video/x-raw-yuv,width=640,height=480 ! \ videoscale ! video/x-raw-yuv,width=640,height=480 ! \ videorate ! video/x-raw-yuv,framerate=3/1 ! \ ffmpegcolorspace ! \ theoraenc bitrate=50 ! \ queue ! mux::file. \ v4lsrc device=/dev/video0 ! \ video/x-raw-yuv,width=640,height=480 ! \ ffvideoscale ! video/x-raw-yuv,width=320,height=240 ! \ videorate ! video/x-raw-yuv,framerate=100/16 ! \ ffmpegcolorspace ! \ theoraenc bitrate=50 ! \ queue ! mux::file. \ oggmux name=mux::file ! \ filesink location=output.ogg
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE 6 Pipeline do Gstreamer para captura de slides via RFB, codificação
VBR e distribuição via Icecast.
gst-launch \ osssrc ! \ audio/x-raw-int,rate=\(int\)44100,depth=16,channels=2 ! \ audioresample ! \ audioconvert ! \ capsfilter ! audio/x-raw-float,rate=\(int\)12000 ! \ vorbisenc bitrate=20480 ! \ queue ! mux::icecast. \ rfbsrc host=192.168.0.180 \ password=SENHA keep-alive=true keep-alive-rate=0.3 ! \ ffmpegcolorspace ! \ ffvideoscale ! video/x-raw-yuv,width=640,height=480 ! \ videorate ! video/x-raw-yuv,framerate=3/1 ! \ theoraenc quality=32 ! \ queue ! mux::icecast. \ v4lsrc device=/dev/video0 ! \ video/x-raw-yuv,width=640,height=480 ! \ ffvideoscale ! video/x-raw-yuv,width=320,height=240 ! \ videorate ! video/x-raw-yuv,framerate=100/16 ! \ ffmpegcolorspace ! \ theoraenc quality=16 ! \ queue ! mux::icecast. \ oggmux name=mux::icecast ! \ shout2send ip=127.0.0.1 port=8000 password=hackme mount=ead.ogg
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE 7 Pipeline do Gstreamer para captura de slides via chamadas ao modo
gráfico do GNU/Linux, codificação VBR, armazenamento em disco e distribuição via Icecast.
gst-launch \ osssrc ! \ audio/x-raw-int,rate=\(int\)44100,depth=16,channels=2 ! \ audioresample ! \ audioconvert ! \ capsfilter ! audio/x-raw-float,rate=\(int\)12000 ! \ vorbisenc bitrate=20480 ! \ queue ! mux::file. \ ximagesrc use-damage=false ! \ video/x-raw-rgb,framerate=3/1 ! \ ffmpegcolorspace ! \ ffvideoscale ! video/x-raw-yuv,width=800,height=600 ! \ theoraenc quality=32 ! \ queue ! mux::file. \ v4lsrc device=/dev/video0 ! \ video/x-raw-yuv,width=640,height=480 ! \ ffvideoscale ! video/x-raw-yuv,width=320,height=240 ! \ videorate ! video/x-raw-yuv,framerate=25/4 ! \ ffmpegcolorspace ! \ theoraenc quality=16 ! \ queue ! mux::file. \ oggmux name=mux::file ! \ tee name=tee::ogg ! \ { queue ! shout2send ip=127.0.0.1 \ port=8000 password=hackme mount=ead.ogg } \ { tee::ogg. ! queue ! filesink location=output.ogg }
