software cliente-servidor para fluxos de vídeo usando o … · servidor para streaming de vídeo,...
TRANSCRIPT
UNIVERSIDADE FEDERAL FLUMINENSE CENTRO TECNOLÓGICO CIENTÍFICO
ESCOLA DE ENGENHARIA DEPARTAMENTO DE ENGENHARIA DE TELECOMUNICAÇÕES
Trabalho apresentado como requisito à conclusão do curso para Engenheiro de Telecomunicações pela Universidade Federal Fluminense.
Software cliente-servidor para fluxos de vídeo usando o
protocolo MMTP
Douglas Vidal Teixeira Fernando Bicalho Canedo Freitas
Orientador: Luiz Claudio Schara Magalhães
Niterói – RJ 2004
2
DEDICATÓRIAS
Dedico este trabalho à minha família, meu pai
Carlos Roberto, minha mãe, Ilca e meu irmão
Carlos, pelo esforço, dedicação, confiança e
acima de tudo pelo amor incondicional que
sempre tiveram por mim.
Douglas Vidal Teixeira
Dedico este à minha família, pelo apoio, carinho
e confiança que sempre me deram.
Fernando Bicalho Canedo Freitas
3
AGRADECIMENTOS
Primeiramente gostaria de agradecer aos meus
amigos da UFF, pelo apoio e companheirismo
que sempre tiveram comigo, mesmo nas horas
mais inconvenientes, em especial André Luiz Sá
Silva, Bruno Mello Lembo, Christiano Freitas
de Souza, David Santos Godoy, Rafael Oliveira
Ribeiro e Rodrigo da Cunha Mangelli.
Ao meu amigo, professor e orientador Luiz
Cláudio Schara Magalhães, não somente por
ser idealizador do projeto, mas pela confiança,
paciência e bom humor que sempre teve conosco.
Douglas Vidal Teixeira Aos bons e verdadeiros professores que tive na
UFF e antes da UFF. Pois, além das equações e
conhecimento dos livros, o que me ensinaram eu
levarei pra vida toda.
Fernando Bicalho Canedo Freitas
4
“Pode-se lembrar que entre os direitos humanos está o direito à educação e, se este
se realizar, os direitos do homem se tornarão também realidade.”
Celso D. Albuquerque Mello
“Aproveite as pequenas coisas, e as maiores tomarão conta delas mesmas.”
Jim Davis
“...os homens não têm de fugir da vida como os pessimistas mas como alegres
convivas de um banquete que desejam suas taças novamente cheias, dirão à vida:
uma vez mais.”
“... sentir-se, como humanidade (e não somente como indivíduo), tão esbanjado
como vemos a florescência isolada ser esbanjada pela natureza, é um sentimento
acima de todos os sentimentos.”
“Onde há inocência? Onde há vontade de gerar. E quem quer criar para além de si,
este tem para mim a mais pura das vontades.
Onde há beleza? Onde tenho de querer com toda vontade; onde quero amar e
sucumbir, para que uma imagem não permaneça apenas uma imagem.”
Friedrich W. Nietzsche
“Só está inclinado a produzir quem se equivoca sobre si mesmo, quem ignora os motivos secretos
de seus atos. O criador que chegou a ser transparente a si mesmo, deixa de criar. O conhecimento
de si indispõe ao demônio.”
E. M. Cioran
5
RESUMO
Atualmente vislumbramos conexões cada vez mais velozes e eficientes. A demanda por fluxos
contínuos torna-se cada vez mais usual. Sites instalam seus provedores de streaming através de
softwares receptores abertos.
Métodos para transmissão de tais fluxos diferem dos métodos utilizados predominantemente pela
internet. Estes utilizam os chamados protocolos de transporte, que são os responsáveis pelo envio de
tais fluxos.
MMTP é um protocolo de transporte ao nível de aplicação que, como os outros já existentes, tem o
intuito de realizar transmissão de dados multimídia. O seu diferencial está em suas técnicas de
predição das condições da rede, de alteração e incorporação de um ou mais canais de conexão
simultaneamente e da utilização de um controle baseado em prioridade.
O quadro de um fluxo mpeg é dividido em sub-quadros, cada um com sua funcionalidade e
importância, que podem ser facilmente hierarquizados. Nosso presente trabalho propõe um estudo
do fluxo mpeg, bem como projetos para o seu processamento em computador. Em seguida,
analisamos os métodos e os protocolos de transporte já utilizados no mercado para a realização de
streaming de vídeo. Finalmente, demonstramos a nossa proposta de criar um software cliente-
servidor para streaming de vídeo, utilizando o protocolo MMTP.
Nossa abordagem traz uma nova perspectiva sobre o conceito de streaming de vídeo na internet,
pelo fato de utilizarmos um protocolo mais versátil com maiores funcionalidades.
6
ÍNDICE Capítulo Título Página 1.
1.1
1.1.1
1.2
Introdução............................................................................................
O Domínio do Video sob Demanda ....................................................
Requisitos tecnológicos.........................................................................
Justificativa............................................................................................
12
15
17
19
2.
2.1
2.1.1
2.1.2
2.1.3
2.1.3.1
2.1.3.2
2.1.3.3
2.1.4
Internet ................................................................................................
A arquitetura da internet .......................................................................
Camada de enlace .................................................................................
Camada de Rede....................................................................................
Camada de transporte ...........................................................................
Endereçamento para as aplicações .......................................................
O protocolo TCP ...................................................................................
O protocolo UDP ..................................................................................
Camada de aplicação ............................................................................
20
20
21
22
22
23
24
25
26
3.
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.2
3.3
3.3.1
3.3.2
3.3.3
3.4
O formato MPEG ...............................................................................
Descrição do Padrão .............................................................................
Espaço de Cores e Subamostragem ......................................................
Estimação e Compensação de Movimento ...........................................
Transformada Discreta de Cosenos ......................................................
Quantização ..........................................................................................
Codificação ...........................................................................................
Resumo do Algoritmo ..........................................................................
Técnicas de compactação .....................................................................
Compactação pela DCT ........................................................................
Compactação no estágio de quantização ..............................................
Compactação por compensação de Movimento ...................................
Comparação das Técnicas e Conclusões ..............................................
28
29
31
33
36
37
40
42
43
43
44
46
49
7
Capítulo
4
Título
O projeto do player de Berkeley para MPEG .................................
Página
52
5
5.1
5.2
5.3
5.3.1
5.3.2
5.3.3
5.4
5.5
5.6
Métodos mais usados na Transmissão de Vídeo ...........................
Métodos tradicionais ...........................................................................
Métodos Recentes – Streaming............................................................
Tipos de Streaming usados na Internet ……………………………...
Stored Audio and Video Streaming …………………………………
Streaming of Live Audio and Video ………………………………...
Real Time Interactive Audio and Video Streaming ………………...
Streaming de vídeo na internet ............................................................
Enviando multimídia de um servidor de streaming para uma
aplicação ..............................................................................................
Problemas do Streaming causados pela Internet .................................
55
55
56
57
57
58
59
59
61
62
6.
6.1
6.1.1
6.2
6.2.1
6.2.1.1
6.2.1.2
6.3
6.3.1
6.4
6.5
6.6
6.7
6.8
6.9
6.9.1
Protocolos de Transporte …………………………………………..
Real Time Transport Protocol (RTP) ………………………………..
Estrutura do cabeçalho RTP …………………………………............
RTP Control Protocol (RTCP) ………………………………………
Estrutura dos pacotes RTC …………………………………………..
RTCP - “Sender Type” ……………………………………………...
RTCP - “Receiver Type” …………………………………...………..
Real Time Streaming Protocol (RTSP) ……………………………...
Mensagens RTSP ……………………………………………………
Seqüência Temporal de uma Sessão ...................................................
Máquina de Estados do RTSP ............................................................. Esquema de Ligações RTP/RTCP/RTSP ............................................ Resource Reservation Protocol (RSVP) ..............................................
Pilha de Protocolos ..............................................................................
Players de Streaming e suas Tecnologias ............................................
Apple QuickTime ................................................................................
68
69
69
71
72
72
74
74
75
78
79
79
80
81
82
83
8
6.9.2
6.9.3
Real Media ..........................................................................................
Windows Media ..................................................................................
86
88
7 MMTP – Multimedia Multiplexing Transport Protocol ............... 92
7.1 Estrutura da comunicação ................................................................... 93
7.2 Características dos Dados ................................................................... 94
7.3 Comportamento inicial ........................................................................ 94
7.4 Controle de fluxo ................................................................................. 97
7.5 Controle de Congestionamento ........................................................... 98
7.5.1 Estimação dos parâmetros ................................................................... 98
7.5.2 Sondagem ............................................................................................ 100
7.6 Adicionando e removendo canais ....................................................... 101
7.7 Comparação entre MMTP e UDP .......................................................
102
8 Desenvolvimento do Software de Streaming ................................... 105
8.1 Primeira fase do projeto ...................................................................... 105
8.2 Segunda fase do projeto ......................................................................
110
9 Considerações finais .......................................................................... 119
9.1 Utilização do software e experimento .................................................
119
9.2 Conclusão e trabalhos futuros .............................................................
120
Apêndice ............................................................................................. 123
Bibliografia ........................................................................................ 144
9
ÍNDICE DE FIGURAS
Número Capítulo Título Página
1 1.2 Evolução da Demanda dos Serviços de TV interativa...................... 15
2 1.2.1 Visão simplificada de um cenário de VoD.......................................
17
3 3.1 Modelo de Referência do Padrão MPEG-1 ..................................... 30
4 3.1 Modelo da parte de vídeo de um sistema MPEG ............................ 31
5 3.1.1 Macroblocos do padrão MPEG ....................................................... 33
6 3.1.2 Efeito do vetor de movimento compensado .................................... 34
7 3.1.2 Modelo MPEG de compensação de movimento ............................. 35
8 3.1.5 O padrão zig-zag para transformar o coeficientes DCT em um
vetor unidimensional .......................................................................
41
9 3.2 Diagrama de blocos do codificador ................................................. 42
10 3.3.1 Comparação entre duas imagens com os mesmos tons cinza mas
com variação espacial diferente .......................................................
43
11 3.3.2 Taxa de compressão em função do Parâmetro de Quantização ....... 45
12 3.3.2 Comparação entre duas imagens com graus de quantização
diferentes ..........................................................................................
45
13 3.3.3 Imagens espelhadas usadas no teste de compensação de
movimento .......................................................................................
46
14 3.3.3 Gráficos de compressão em função da configuração ...................... 48
15 5.2 Entrega de dados e controle entre Servidor/Cliente .............................................. 57
16 5.6 Atraso na reprodução ....................................................................... 64
17 5.6 Envio tipo “Interleaving” ................................................................. 66
18 6.1 Modelo Ozi de Camadas ................................................................. 65
19 6.1.1 Estrutura do cabeçalho do RTP........................................................ 70
20 6.1.1 Explicação dos Campos do Cabeçalho do RTP................................ 71
21 6.2.1.1 Estrutura de um pacote RTCP Sender Type..................................... 72
22 6.2.1.1 Explicação dos Campos do pacote RTCP Sender Type................... 73
23 6.2.1.2 Estrutura de um pacote RTCP “Receiver Type”............................... 74
10
24 6.4 Esquema temporal de troca de mensagens ...................................... 78
25 6.5 Máquina de Estados RTSP............................................................... 79
26 6.6 Esquema de ligações dos protocolos ............................................... 80
27 6.8 Pilha de Protocolos .......................................................................... 82
28 6.9.1 Exemplo mensagem SDP de um servidor ....................................... 84
29 6.9.1 Exemplo de atributos da mensagem SDP ........................................ 85
30 6.9.1 Exemplo do esquema de mensagens da Apple ................................ 85
31 6.9.2 Exemplo do esquema de mensagens da Real ........................................................ 87
32 6.9.3 Arquitetura de Alto Nível da Troca de Multi-rate ........................... 91
33 7.3 Comportamento incial para o MMTP com dois canais.................... 96
34 7.7 Comparação entre UDP, MMTP e máxima teórica para pacotes
versus periodicidade. .......................................................................
103
35 7.7 Pacotes recebidos após seus prazos ................................................. 104
11
ÍNDICE DE TABELAS
Número Capítulo Título Página
1 3.3.1 Efeito da presença de altas freqüências espaciais na imagem ......... 44
2 3.3.3 Efeito da semelhança entre as imagens na compactação ................. 47
12
Capítulo 1
1. Introdução
Atualmente vemos uma crescente demanda pelo serviço de Vídeo On Demand. Não apenas pela
crescente necessidade de comunicação, mas pela facilidade cada vez maior disponibilizada pelas
redes de alta velocidade. Sem dúvida nenhuma vislumbramos um período de mudanças nessa área
da tecnologia. Equipamentos cada vez mais potentes, com maior velocidade de processamento e
armazenamento evoluem a cada dia, juntamente com os estudos nas comunicações de dados. Com o
advento da fibra óptica e das melhorias nos equipamentos de processamento digital, as
comunicações passaram a ter uma nova utilidade no dia-a-dia, mesmo em países em
desenvolvimento, devido às facilidades e às velocidades que elas passaram a incorporar.
O fluxo de dados em alta velocidade trouxe diversas comodidades nunca antes experimentadas pela
população em geral. O que antes era restrito à pequenas redes corporativas, governamentais ou
militares, passou a abranger cada indivíduo portador de um computador pessoal e de algum meio de
acesso à internet. A World Wide Web mudou nas duas últimas décadas a forma com a qual as
pessoas lidavam com os meios de comunicação. Desde um acesso a páginas pessoais através de
uma conexão discada, até a comunicação com som e imagem em tempo real entre extremos do
globo através de conexões mais rápidas como redes à cabo, o xDSL, etc. À medida que mais e mais
pessoas passaram a incorporar as redes de alta velocidade, serviços novos e melhores tiveram de ser
implementados. Dentre eles destacamos o VoD, ou seja, uma conexão entre um ou mais clientes a
um servidor demandando um serviço de vídeo, seja este um filme, uma transmissão ao vivo via
WebCam ou uma comunicação interativa via TV Digital. Para tanto, mesmo dispondo da alta
velocidade, esta não é suficientemente eficaz quando tratamos de fluxos de áudio e vídeo, devido à
grande quantidade de dados agregados a eles e devido a velocidade com que eles tem de ser
transmitidos.
O crescimento acelerado da Internet tem determinado um aumento do seu leque de serviços,
visando atender às diversas necessidades dos usuários. A princípio existiam apenas páginas HTML
com apenas textos e imagens estáticas, os correios eletrônicos e as conseqüentes transferências de
13
arquivos entre computadores. Porém, segundo [1], nos últimos anos, a Internet começa a obter
sucesso crescente em áreas como comércio eletrônico e outras formas de comunicação eletrônica.
Apesar das altas taxas de transmissão, não é possível transmitir em tempo real um arquivo de vídeo
de porte razoável sem técnicas de compressão e compactação. Tais técnicas fogem ao escopo do
trabalho aqui apresentado, no entanto, podemos afirmar com um simples exemplo, a inviabilidade
desse tipo de transmissão sem o tratamento adequado. Mais informações sobre codificação sobre
imagens podem ser obtidas em [2]:
Considere um quadro de um fluxo de vídeo de qualidade VGA (baixa qualidade), ou seja, cada
quadro consiste em uma imagem de 640x480 pixels, cada um codificado por 8 bits. Considere uma
alta taxa de transmissão, como por exemplo 1.5 Mbps. Teremos então:
6
640 480 81,6384
1.5 10
× ×=
×s
Ou seja, mesmo um vídeo de baixa qualidade com uma rede
de alta velocidade teria 1,6384 segundos para cada quadro,
o que é muito lento sabendo-se que 1 segundo de vídeo possui
pelo menos 24 quadros, segundo [3].
O streaming multimídia, uma técnica para transferência de dados na qual transmite-se áudio e/ou
vídeo através da Internet (ou alguma outra rede) em tempo real, destaca-se entre tais novas formas
de comunicação, conhecida como webcasting. De acordo com [4], essa nova tecnologia pode servir
aos mais variados interesses, que vão da videoconferência ao vídeo sob demanda, passando pelo
Web TV até os jogos interativos.
Segundo [1], o streaming é uma tecnologia relativamente nova, pois, nos princípios da Internet, os
arquivos de vídeo tinham de ser transferidos por inteiro para o disco rígido do usuário antes de
serem vistos ou ouvidos. Assim, o usuário tinha de esperar até que o arquivo fosse transferido na
sua totalidade para então poder visualizá-lo. Atualmente, as principais tecnologias de streaming de
cunho comercial utilizadas na Internet pertencem à Real Networks (http://www.real.com) através do
Real Player e à Microsoft (http://www.microsoft.com), com o Windows Media Player.
14
O software desenvolvido neste trabalho foi especificado e implementado baseado na arquitetura
cliente/servidor, utilizando a linguagem C, em plataforma Linux, onde:
a) o servidor realiza a captura do sinal externo de vídeo e o transmite para os
clientes que estão conectados;
b) o cliente conecta-se ao servidor e controla a exibição do vídeo na tela. Para a troca de mensagens
entre os programas, foi implementado o protocolo MMTP (Multimedia Multiplexing Transport
Protocol), [5], permitindo que o cliente solicite ao servidor o início e término da transmissão de
streaming de vídeo. O mesmo protocolo também é utilizado para o envio do sinal de vídeo aos
clientes conectados.
De todos esses conteúdos acima vistos, este trabalho vai incidir essencialmente naquele que
representa já uma grande maioria da transmissão de vídeo na Internet – a transmissão em tempo real
ou ao vivo, isto é, transmissão com metas temporais a cumprir, ou por outro nome, o “Vídeo
Streaming”. Primeiramente abordaremos a estrutura da internet, nosso principal meio de interesse
de transmissão, assim como a sua arquitetura. Em seguida faremos uma explicação sobre a
formação de um fluxo de quadros MPEG, ou seja, como um arquivo de vídeo nesse formato é
codificado e “compreendido” pelo computador. Continuando, faremos uma abordagem sobre o
projeto base de nosso software, o player de MPEG desenvolvido pela universidade de Berkley.
Começar-se-á, então, a falar dos diferentes métodos existentes para se obter comunicação
multimídia em qualquer dispositivo com uma ligação à Rede Global (Computador Pessoal, PDA -
Personal Digital Assistent, Telefone Móvel, entre outros), seguida de uma explicação do que são e
de como funcionam os Protocolos usados por esses métodos. Terminando a parte teórica, iremos
expor o protocolo utilizado pelo software, o MMTP. Finalizando, apresentaremos a parte prática de
nosso trabalho, explicando como chegamos ao nosso software, ilustrando através das partes mais
significativas do código realizado.
1.1 O Domínio do Video sob Demanda Diferentemente de um sistema de televisão tradicional, onde o telespectador é um agente passivo,
que tem acesso ao serviço sem nenhuma interação com as informações a ele transmitidas, um
sistema de vídeo sob demanda (VoD – video on demand system), por outro lado, é um sistema
multimídia que oferece aos seus usuários a funcionalidade de acesso a um servidor remoto de
15
vídeos (por exemplo, a partir de um terminal presente em casa ou escritório), atuando sobre o
mesmo em vários níveis de interação e com ampla liberdade de escolha de programação. As
conexões de vídeo são estabelecidas sob demanda, através de uma rede de comunicação que liga o
cliente ao servidor de vídeo.
Sistemas de vídeo sob demanda têm um potencial enorme de aplicação e alguns protótipos vêm
sendo desenvolvidos, em particular nas áreas de educação, medicina e entretenimento. Diversos
estudos de comportamento feitos com usuários nos EUA mostram que o serviço de APPV
(Advanced Pay-Per-View), que é um dos tipos de serviço de vídeo sob demanda, será o serviço mais
utilizado nos próximos anos, sendo no futuro superado pelos serviços de jogos interativos sob
demanda e o verdadeiro serviço de vídeo sob demanda, ambos sempre se apresentando com um
potencial de mercado muito grande [6] (figura 1).
Figura 1- Evolução da Demanda dos Serviços de TV Interativa [6] Os sistemas de VoD podem ser classificados como a seguir, de acordo com seu grau de
interatividade [7]:
1. Broadcast (No VoD): Sistema de difusão de TV sobre o qual o usuário não tem nenhuma
interação. Dessa forma, não constitui na verdade um sistema de VoD, sendo classificado apenas em
caráter de comparação.
2. PPV (Pay-per-view): Sistema similar ao que existe hoje na TV por assinatura, em que o usuário
escolhe e paga por uma determinada programação que deseja assistir (similar aos serviços PPV
atualmente existentes nos ambientes de CATV e DBS – Direct Broadcast Satellite.
16
3. QVod (Quasi VoD): Esta modalidade é baseada em segmentos temporais, múltiplos da duração
do filme. Cada usuário tem direito a escolher o vídeo que deseja assistir. Imediatamente após a
escolha, o sistema tenta agrupar dentro de um mesmo segmento temporal todos os usuários que
demandam por um mesmo vídeo. Se no exato momento em que o usuário escolhe um vídeo para
assistir a exibição deste filme estiver começando, o usuário irá recebê-lo imediatamente, caso
contrário será obrigado a esperar até o início do próximo segmento.
4. NVoD (Near VoD): Este caso se apresenta como uma extensão do QVoD, no que diz respeito ao
poder de controle disponibilizado para o usuário. Apesar de ainda não possuir uma transmissão
exclusiva para cada usuário, possibilita algum controle sobre a exibição do vídeo. Porém, esta
interação está associada aos segmentos temporais, no sentido de que o usuário só pode retroceder,
adiantar ou fazer uma pausa no vídeo em intervalos temporais múltiplos destes segmentos. É
importante ressaltar a preocupação que deve ser tomada na escolha do segmento temporal, pois o
que temos aqui é uma troca entre um maior nível de interação (segmentos menores) e uma maior
economia de largura de banda (segmentos maiores).
5. TVoD (True VoD): Neste caso, o usuário tem acesso a todas as funções de um videocassete
virtual, podendo então exercer o controle total sobre a execução do vídeo. É como se existisse um
canal exclusivo para cada usuário, pois mesmo que dois usuários decidam assistir a um mesmo
filme simultaneamente, muito provavelmente os dois irão interagir com o mesmo de formas
diferentes.
O domínio modelado neste trabalho é um serviço de streaming de vídeo. Apesar disso, é importante
ser dito que o objetivo futuro desse trabalho é servir de suporte à uma plataforma completa para ura
vídeo sob demanda ou simplesmente VoD.
Para que um serviço de vídeo sob demanda possa ser oferecido, vários são os requisitos
tecnológicos necessários. Alguns deles exercem uma influência direta nas possibilidades de
concretização dos subsistemas que compõem a arquitetura do serviço, nos seus modelos de
distribuição e, em última instância, na ontologia de VoD que será produzida. A seguir, são
discutidos os principais requisitos deste tipo e as alternativas existentes para endereçá-los, tanto do
ponto de vista tecnológico quanto econômico. Por fim, é interessante observar a influência que
requisitos dessa natureza têm na proposição de arquiteturas conceituais.
17
1.1.1 Requisitos Tecnológicos
A Figura 2 mostra uma ilustração simplificada de como um serviço de vídeo sob demanda é visto
do ponto de vista do usuário. O cenário é composto de três subsistemas: o terminal através do qual o
usuário tem acesso ao serviço, o servidor de vídeos digitalizados e o sistema de comunicação
responsável por fazer a conexão entre os dois.
Figura 2 - Visão simplificada de um cenário de VoD
Os principais requisitos tecnológicos impostos a um sistema desse tipo estão ligados ao seu
comprometimento com o transporte, armazenamento e apresentação de mídias contínuas, como
áudio e vídeo, e dessa forma, exercem um impacto diretamente em todos os subsistemas citados.
Esses tipos de mídia são notórios pela alta demanda de desempenho que impõem ao sistema,
principalmente no que diz respeito ao espaço de armazenamento e largura de banda de transmissão
requerida e pela validade temporal de seus dados. Para melhor exemplificar esta necessidade,
utilizaremos o seguinte exemplo:
1. Suponha um frame de vídeo com resolução de 640x480 pixels, agora com profundidade de 24
bits (definição de formato SVGA). Este frame sozinho ocupa um espaço de 640x480x3 bytes = 900
Kbytes.
18
2. Considerando uma taxa de frames de 30 frames/s (requisito para padrão NTSC), então um
segundo deste vídeo necessita de uma largura de banda de transmissão de aproximadamente 27
Mbytes/s.
3. Em média, um filme tem duração de 90 minutos (1 1/2 hora), portanto, um único filme requer,
em média, 143 GB de espaço de armazenamento.
4. Agora suponha que este vídeo possui também um áudio stereo associado, com qualidade de CD
(16 bits/amostra e taxa de amostragem de 44100 Hz). Um segundo deste áudio ocupa
aproximadamente 88 KB e, portanto, o áudio de um único filme de 90 minutos ocupa cerca de 475
MB de espaço de armazenamento.
Por estas razões proibitivas, o desenvolvimento de bons algoritmos de compressão específicos para
estes sistemas tornou-se crucial para o desenvolvimento de aplicações multimídia distribuídas em
geral. Os principais formatos usados para codificação de mídias contínuas são os padrões ITU-T
H.263 e ISO MPEG - Motion Pictures Expert Group [8], sendo esse último o recomendado pelo
DAVIC - DIGITAL Audio Visual Council [9], para aplicações de VoD. Taxas de compressão
típicas alcançadas pelo MPEG são de 100:1 para vídeo e 10:1 para áudio. Apesar da redução
significativa alcançada, a largura de banda de transmissão requerida ainda é grande o bastante para
influenciar diretamente na escolha das alternativas de implementação dos subsistemas que
compõem o serviço. Os padrões MPEG atualmente existentes para codificação de vídeo são:
MPEG-1, MPEG-2 e MPEG-4 (o padrão MPEG-3 que seria usado nas aplicações de HDTV foi
descartado pelo grupo) [10].
1.2 JUSTIFICATIVA Conforme a descrição anterior, atualmente já existem alguns softwares que podem ser facilmente
adquiridos e parametrizados de modo a disponibilizar um sinal de vídeo na Internet. Porém, não
importando qual seja sua procedência, um software dessa categoria deve seguir um conjunto de
especificações padrão definidas por grupos de estudo como a IETF (Internet Engineering Task
Force) para que o sinal possa ser transmitido e visualizado por qualquer computador conectado à
rede mundial.
19
Como a Internet não foi inicialmente constituída para a transmissão desse tipo de informação, com
pouca largura de banda e um crescente número de computadores domésticos conectados à ela,
torna-se um desafio implementar uma aplicação para esse fim que possa oferecer ao usuário uma
transmissão com qualidade aceitável. Além disso, a transmissão de vídeo envolve um grande
volume de dados e a necessidade de transmissão síncrona e em tempo real requerem certos cuidados
que deverão ser considerados durante o estudo.
A importância deste trabalho está em apresentar um software capaz de realizar a comunicação
cliente-servidor para a demanda de fluxos de vídeo em tempo real, minimizando atrasos e falhas
decorrentes do meio de transmissão. A utilização do protocolo MMTP permitirá que a transmissão
do fluxo de vídeo torne-se mais confiável, rápida e acessível, não somente para computadores
pessoais, mas também para PDA’s e celulares da geração 2.5 em diante.
20
Capítulo 2 2. Internet A Internet é um conjunto de redes de computadores interligadas pelo mundo inteiro, que têm em
comum um conjunto de protocolos e serviços de informação e comunicação de alcance mundial
[11].
Pode-se definir a Internet como uma verdadeira comunidade virtual, formada por todos os usuários
dessas redes de computadores com os mais diversos intuitos: troca de mensagens no correio
eletrônico, debates ao vivo (IRC – Internet Relay Chat), grupos de discussão (Usenet e Mailing
List), entretenimento (jogos), e até comércio. Em virtude da riqueza de possibilidades criou-se o
conceito de cyberspace, ou espaço cibernético, um mundo eletrônico paralelo altamente
democrático, onde já começa a se formar uma base de conhecimento universal [12]. Para [12], os
padrões da Internet não são criados por órgãos internacionais de padronização, como a International
Organization for Standardization (ISO) ou o Institute of Electrical and Electronics Engineering
(IEEE), porém, sua arquitetura é muito aceita, sendo chamada por isso como padrão “de facto”, ao
contrário do modelo Open System Interconnection (OSI), considerado padrão “de jure”.
Na verdade, diversos grupos orientam o crescimento da Internet auxiliando no estabelecimento de
padrões e orientando as pessoas sobre a maneira adequada de utilizá-la. Talvez o mais importante
seja a Internet Society, um grupo privado sem fins lucrativos que suporta o trabalho da Internet
Activities Board (IAB), que coordena a elaboração de padrões e protocolos da Internet e designa
endereços IP da rede através da Internet Assigned Numbers Authority (IANA) [13].
2.1 A arquitetura da internet A Internet é a mais bem sucedida aplicação prática do conceito de internetworking, que consiste em
conectividade de redes de tecnologias distintas; essa conectividade foi conseguida pelo uso do
conjunto de protocolos conhecido como TCP/IP, que surgiu em 1975 na rede ARPANET. Suas
especificações são públicas e genéricas, o que permite a implementação por diversos fabricantes. O
TCP/IP (Transmission Control Protocol / Internet Protocol), ao contrário do que parece, não é
apenas um protocolo, mas uma família. Enquanto o IP é responsável pelo encaminhamento de
21
pacotes de dados entre diversas sub-redes desde a origem até o destino, o TCP, tem por função o
transporte fim-a-fim confiável de mensagens de dados entre dois sistemas [12].
Na pilha de protocolos TCP/IP, o endereçamento é especificado pelo IP (Internet Protocol), onde a
cada host1, é atribuído um número de 32 bits único conhecido como endereço IP. Cada pacote
enviado através de uma inter-rede contém o endereço IP do remetente (origem) e do receptor
pretendido (destino) [14]. O TCP fornece um serviço de transporte de dados orientado à conexão,
full-duplex e totalmente confiável (nenhuma duplicação ou perda de dados), que permite a dois
programas aplicativos formarem uma conexão, enviarem dados em uma ou outra direção e então
terminarem a conexão. Cada conexão de TCP é iniciada confiavelmente e terminada graciosamente,
com todos os dados sendo entregues antes da terminação da conexão acontecer [11]. Para uso em
redes de alta qualidade ou em conexões onde o problema de confiabilidade não assume grande
importância, foi definido o protocolo UDP (User Datagram Protocol) que opera no modo sem
conexão e possui funcionalidades bem mais simples que o TCP.
Segundo [15], o modelo de referência TCP/IP, especificado pela IETF2, é baseado em um conjunto
de quatro camadas, a ver:
2.1.1 Camada de enlace
Consiste em rotinas de acesso à rede física. A camada de enlace interage com o hardware,
permitindo que as demais camadas sejam independentes do hardware utilizado. A arquitetura
Internet não define um padrão para a camada física de acesso ao meio, permitindo, portanto,
empregar qualquer tecnologia para interconectar um sistema computacional a uma rede Internet,
bastando para isso que sejam desenvolvidas as respectivas interfaces de comunicação entre o IP e
cada rede.
Dessa forma, pode-se encontrar uma grande variedade de tecnologias diferentes de redes, cada uma,
possuindo seus próprios protocolos, esquemas de endereçamento, taxas de transmissão e meios
físicos. Todavia, tais tecnologias precisam ser vistas pela Internet como se fossem iguais. A
compatibilidade de tais redes é realizada com ajuda dos gateways, que permitem que conjuntos de
1Um computador de usuário final conectado a uma rede. Em uma inter-rede, cada computador é classificado como um host ou um roteador 2 The Internet Engineering Task Force: grupos de pesquisadores e técnicos responsáveis pelo desenvolvimento de padrões para o funcionamento da Internet. Fonte: [15]
22
redes heterogêneas interoperem, enxergando de um lado as redes aos quais está interconectado e, de
outro lado, enxergando uma rede IP, que utiliza um esquema padronizado de endereçamento.
Deste modo, as diferenças existentes entre as redes interconectadas tornam-se transparentes ao
usuário do sistema [16]. Dentre as tecnologias de rede existentes, podemos citar: Ethernet, Token
Ring, FDDI (Fiber Distributed Data Interface), X.25, Frame Relay, ATM, etc.
2.1.2 Camada de Rede
A camada de rede, também chamada de Inter-Rede, é responsável pelo endereçamento dos
equipamentos e pelo roteamento dos dados na rede. O endereçamento de equipamentos na Internet é
baseado em um identificador que independe da tecnologia de rede envolvida, conhecido como
endereço IP. Este endereço, em modo normal, está associado a um único equipamento,
identificando a rede e o equipamento nessa rede. Existe também um outro modo de endereçamento
conhecido como endereçamento multicast, em que um endereço IP está associado a um grupo de
computadores [11].
O roteamento na Internet usa o endereço carregado pelo protocolo IP (Internet Protocol), que é o
responsável pelo encaminhamento dos protocolos da camada de transporte que, por sua vez, são
responsáveis por protocolos que entregam as informações geradas pelas aplicações aos seus
destinatários (chamados protocolos de aplicação). De acordo com [16], o IP é o principal protocolo
desta camada e opera no modo datagrama, isto é, sem conexão. Isso significa que não são pré-
estabelecidos circuitos virtuais entre a origem e o destino para o transporte dos pacotes de dados.
Segundo [12], a operação no modo datagrama é uma comunicação não confiável, não sendo usado
nenhum reconhecimento fim-a-fim ou entre nós intermediários, nem qualquer tipo de controle de
fluxo. Nenhum mecanismo de controle de erro de dados é utilizado, apenas um controle de
verificação do cabeçalho, para garantir que os gateways encaminhem as mensagens corretamente.
2.1.3 Camada de transporte
A camada de transporte tem como principal objetivo prover a transferência confiável de dados entre
processos de diferentes estações pertencentes ou não à mesma rede, garantindo que os dados sejam
entregues livres de erro e em seqüência, sem perdas ou duplicação, liberando, portanto, as camadas
superiores dessas arquiteturas do encargo de gerenciar a infra - estrutura de comunicação usada
pelos mais variados tipos de aplicação.
23
Para a camada de transporte, a arquitetura Internet especifica dois tipos de protocolos:
a) TCP (Transmission Control Protocol): fornece um serviço orientado à conexão para a camada
de aplicação, garantindo a entrega dos dados na ordem correta;
b) UDP (User Datagram Protocol): fornece um serviço sem conexão para a camada de aplicação e
não garante a entrega dos dados, mas apresenta menos sobrecarga que o TCP.
A utilização de um ou de outro protocolo depende das necessidades da aplicação considerada
(qualidade de serviço, tipo de dados, etc.). Dentro da arquitetura Internet, aplicações tais como a de
gerenciamento, utilizam o UDP, e outras, como a de transferência de arquivos, utilizam o TCP.
2.1.3.1 Endereçamento para as aplicações
O endereçamento dos programas aplicativos é realizado pela camada de Transporte, e é baseado em
um identificador conhecido como port. Esse identificador é um número de 16 bits que pode assumir
valores entre 1 e 65535. Para obter uma porta em uma Internet, um programa abre um canal de
comunicação com a camada de Transporte, escolhendo um de seus protocolos e um valor para esse
identificador; a partir de então, passa a ter a possibilidade de se comunicar com outros programas
que rodam nos demais equipamentos dessa Internet.
Embora esse processo de abertura de canal varie conforme o Sistema Operacional dos
equipamentos, ele é sempre identificado por esse número. A associação entre os valores numéricos
dos ports e os programas de aplicação não é unívoca, isto é, mais de um programa pode estar
usando um mesmo número de port, bem como um programa pode abrir mais de um canal com a
camada de Transporte, e, portanto, ter mais de um identificador associado. Assim, a comunicação
entre programas de aplicação em uma rede TCP/IP se dá baseada em três parâmetros: o endereço IP
dos equipamentos em que os programas rodam, o protocolo da camada de Transporte escolhido
para a comunicação (TCP ou UDP), e os valores dos ports escolhidos pelos programas. Essa tríade
de parâmetros em cada programa constitui um end-point, ou socket.
A alocação de um port em um equipamento pode ser feita de forma livre (alocação do primeiro port
livre, por exemplo) ou específica (alocação de um port predeterminado), sendo o uso de uma das
duas formas adotado conforme o tipo de aplicação envolvido. Em aplicações baseadas no modelo
cliente/servidor, os valores dos ports usados pelo programa servidor são predeterminados, enquanto
o programa cliente pode usar valores quaisquer para esse identificador. Por exemplo, na aplicação
24
Telnet, que usa o protocolo de transporte TCP, o programa servidor utiliza o port 23. Do ponto de
vista do servidor, tem-se a seguinte tabela que relaciona os fluxos de dados entre os programas:
Fonte: [17]
Para as aplicações padrão existentes na Internet são reservados alguns valores de port combinados a
um dos protocolos de transporte:
2.1.3.2 O protocolo TCP
O TCP é um protocolo da camada de transporte orientado à conexão que fornece um serviço
confiável de transferência de dados fim-a-fim, implementando mecanismos de recuperação de
dados perdidos (retransmissões), danificados ou recebidos fora de seqüência, o que aumenta o
atraso de trânsito para transmissão dos dados. O TCP assume que pode obter um serviço de
datagrama simples e, potencialmente, não-confiável dos protocolos das camadas inferiores [17].
Conforme [17], a descrição do TCP especifica as seguintes características do protocolo:
a) o formato das mensagens que as duas estações trocam entre si;
b) os procedimentos que as estações utilizam para assegurar que os dados cheguem corretamente,
recuperando erros de perda ou duplicação de mensagens;
c) o modo pelo qual o protocolo faz a distinção entre múltiplas destinações em uma determinada
estação;
25
d) o modo pelo qual as duas estações devem iniciar uma transferência e, também, entrar em acordo
sobre quando a comunicação está completa.
A unidade de transferência de dados trocada entre estações usando o protocolo TCP é chamada de
segmento. Esse segmento é formado por dados oriundos da camada de aplicação, aos quais são
adicionadas as informações necessárias para execução do protocolo. Dessa forma, um segmento
TCP trafega por uma Internet TCP/IP encapsulado em datagramas IP. O TCP é usado nas seguintes
situações:
a) quando as aplicações necessitam dos mecanismos que controlam o tráfego de dados entre os
sockets;
b) quando os dados de uma aplicação são essenciais, necessitando verificar se os dados chegaram ao
destino corretamente;
c) quando a qualidade e a eficiência da rede não são elevadas, podendo ocasionar erros na
transmissão.
2.1.3.3 O protocolo UDP
O UDP é um protocolo de transporte pertencente à família de protocolos TPC/IP que fornece um
serviço mínimo de transporte em redes que usam o protocolo IP, permitindo que as aplicações
tenham acesso direto aos serviços da camada de rede. O tipo de serviço fornecido pelo UDP tem as
seguintes características:
a) não orientado à conexão;
b) transmissão não confiável.
O fato de ser não orientado à conexão significa que um datagrama pode ser enviado a qualquer
momento, sem qualquer tipo de aviso, negociação ou preparação com o host destino. É esperado
que o host de destino esteja preparado para receber e processar os datagramas. O fato do protocolo
não ser confiável significa que:
a) não existe nenhuma garantia de que os datagramas sejam entregues no destino;
b) não existe registro dos datagramas enviados;
c) os datagramas podem chegar fora de ordem;
d) os datagramas podem chegar duplicados;
e) não existe controle de fluxo;
f) não existe controle de congestionamento na rede.
26
Deste modo, compete às aplicações que usam o UDP, implementar mecanismos de detecção e
correção de erros, de modo a garantir que os datagramas cheguem corretamente ao destino. Embora
as características do serviço prestado pelo UDP sejam as mesmas que as da camada IP, este vem
acrescentar dois serviços que a camada IP não disponibiliza:
a) a capacidade de distinguir um dentre os vários processos que estejam a usar os serviços da
camada de rede num mesmo host (multiplexação/demultiplexação);
b) a capacidade de verificação da exatidão dos dados recebidos.
O UDP é usado nas seguintes situações:
a) quando as aplicações não necessitam do nível de serviço que o TCP fornece; o uso do UDP
diminui a complexidade no processamento dos datagramas;
b) quando os dados de uma aplicação não são essenciais, como por exemplo um query DNS. Se a
resposta não chegou volta-se a perguntar;
c) quando a qualidade e a eficiência da rede é elevada.
2.1.4 Camada de aplicação
A camada de aplicação consiste nas aplicações e processos que utilizam a rede. Qualquer usuário
pode criar suas aplicações, pois o TCP/IP é uma arquitetura aberta, ou seja, não existe um padrão
que defina como deve ser estruturada uma aplicação [11].
Segundo [12], o nível mais alto desta arquitetura tem por função efetuar a interface com as
aplicações que desejam utilizar os meios de comunicação de dados. A arquitetura provê aplicações
padronizadas para as principais tarefas do segmento de comunicação de dados. Exemplos de
protocolos de aplicação:
a) Telnet: permite ao usuário de um sistema acessar remotamente outro sistema através de uma
sessão de terminal;
b) File Transfer Protocol (FTP): provê serviços de transferência, renomeação e remoção de
arquivos e diretórios remotamente;
c) Simple Mail Transfer Protocol (SMTP): provê uma interface com o usuário para enviar e
receber mensagens;
d) HTTP (HyperText Transfer Protocol): implementa o serviço World Wide Web que provê uma
interface (normalmente um Web Browser) para visualização de páginas Web, em formato HTML;
27
e) SNMP (Simple Network Management Protocol): desenvolvido para utilização em um modelo
cliente/servidor de aplicações de gerência, cabendo ao programa gerente o papel de cliente; e aos
agentes, o de servidor, caracterizando-se pela implementação das ações de gerenciamento baseada
em consultas e atualizações de variáveis (objetos) das entidades gerenciadas;
f) POP (Post Office Protocol): utilizado para receber mensagens de correio eletrônico, permitindo
ao usuário acessar a caixa postal onde suas mensagens foram entregues, copiando-as para sua
máquina.
28
Capítulo 3 3. O formato MPEG A compressão de vídeo MPEG é usada em produtos atuais e emergentes. Ela está no coração das
TV's digitais, decodificadores HDTV, leitores DVD, vídeo conferências, vídeo pela Internet e
outras aplicações. Estas aplicações são beneficiadas pela compressão de vídeo pois requerem pouco
espaço de armazenamento, pouca largura de banda na transmissão de informação de um ponto para
outro ou uma combinação destas duas características. Além do MPEG trabalhar bem em uma
grande variedade de aplicações, muito de sua popularidade vem do fato de que são definidos três
padrões internacionais finalizados e um quarto em processo de definição.
A sigla MPEG vem de Moving Picture Expert Group [18], grupo que trabalha para gerar
especificações junto à ISO (International Organization for Standardization) e IEC (International
Electrotechnical Commission). O que é comumente chamado de “vídeo MPEG” de fato consiste
atualmente em três padrões finalizados, MPEG-1, MPEG-2 e MPEG-4 e outro, MPEG-7 em
definição. Os padrões MPEG-1 e MPEG-2 são semelhantes em conceitos básicos. Ambos estão
baseados em técnicas baseadas em codificação através de transformadas enquanto MPEG-4 e
MPEG-7 divergem destas aproximações mais tradicionais e usa técnicas de construção da imagem.
O padrão MPEG-1 foi finalizado em 1991, e foi originalmente otimizado para trabalhar em
resoluções de vídeo de 352x240 pixels a 30 quadros/s (baseado no padrão NTSC) ou 352x288
pixels a 25 quadros/s (baseado no padrão PAL) e era comumente chamado de Vídeo SIF (Source
Input Format). De fato este padrão pode trabalhar com altas resoluções como 4095x4095 a 60
quadros/s. A taxa de transmissão foi otimizada para aplicações em torno de 1,5 Mb/s, mas
novamente pode ser usado em taxas maiores se necessário. MPEG-1 é definido somente para
quadros progressivos ou seja, não pode ser usado em aplicações de vídeo entrelaçado como em
transmissão de televisão.
29
3.1 Descrição do Padrão
O primeiro padrão desenvolvido pelo grupo MPEG, chamado MPEG-1, é o código que combina
sinais audiovisuais a uma taxa de 1,5Mb/s. Ele foi motivado pelo fato de que se estava tornado
possível em 1988 armazenar sinais de vídeo em CD's com qualidade comparável às fitas cassete
VHS.
MPEG-1 foi um padrão muito inovador. Pela primeira vez um único padrão audiovisual foi
produzido e todas as precauções foram tomadas para que as peças do padrão se encaixassem. O
sucesso causado pelo padrão fez com que várias empresas que até então possuíam departamentos de
áudio e vídeo independentes se reorganizassem. Além disso o padrão foi o primeiro em outras
coisas:
• primeiro padrão para processamento de sinais desenvolvido usando código em “C”;
• primeiro código de vídeo independente do formato do vídeo;
• primeiro padrão a incluir implementação em software.
Deve ser notado que, em se manter o principio de “especificar o mínimo”, o padrão MPEG somente
especifica o decodificador e não o codificador.
MPEG-1 é um padrão que fornece uma apresentação normalizada o que permite aos
desenvolvedores realizar o tradicional paradigma dos sistemas de comunicação. Isto pode ser visto
na Figura 3. A informação audiovisual pode ser gerada em tempo real de um acontecimento natural
ou vir de um servidor. Em ambos os casos um fluxo de bits multiplexado chega ao decodificador
através de um meio de distribuição (uma rede de comunicação, um canal de transmissão, etc.). No
caso de um disco local a parte de distribuição do modelo desaparece, mas o restante continua
válido. Os fluxos de áudio e vídeo codificados, forçados a ter uma base de tempo comum e
combinados em um mesmo fluxo pela camada de sistema do MPEG, são extraídos e manipulados
pelos decodificadores de áudio e vídeo apropriados que produzem seqüências de amostras PCM
representando informação de som e imagem.
30
Figura 3: Modelo de Referência do Padrão MPEG-1
O padrão MPEG-1, formalmente conhecido como ISO/IEC 11172, é dividido em 5 partes. As três
primeiras partes são Sistema, Vídeo e Áudio respectivamente. As outras duas partes são: Teste de
Conformidade, que especifica a metodologia para verificação das exigências de conformidade do
padrão pelos fabricantes de equipamentos, e Software Simulation, uma implementação na
linguagem C do codificador e decodificador do padrão MPEG-1.
Em geral, seqüências de vídeo contêm uma quantidade significativa de redundância estatística e
subjetiva entre e nos quadros. O objetivo final de um sistema de codificação de vídeo é a redução
do número de bits a serem armazenados ou transmitidos explorando as redundâncias e codificando
um conjunto mínimo de informação usando técnicas de codificação por entropia. A performance
das técnicas de compressão de vídeo dependem da quantidade de redundância contida na imagem,
bem como nas técnicas usadas na codificação.
A codificação de vídeo MPEG são estatísticas por natureza. A propriedade estatística básica sobre a
qual esta codificação se baseia é correlação entre pixels (inter-pel correlation) incluindo a
suposição de simples correlação de movimento translacional entre quadros consecutivos. Os
algoritmos de compressão MPEG usam técnicas de Transformada Discreta de Cosenos (Discrete
Cosine Transform - DCT) em blocos de imagem de 8x8 pixels para explorar de forma eficiente a
correlação espacial entre pixels próximos na mesma imagem. Entretanto, se a correlação entre os
31
pixels em quadros próximos é alta, por exemplo quando dois quadros consecutivos tem conteúdo
similar ou idêntico, é desejado que seja usado uma codificação DPCM Differential Pulse Code
Modulation entre quadros (intra-frames) executando um predição temporal (motion compensated
prediction between frames). O código MPEG é então uma combinação adaptativa de uma predição
de movimento compensado seguido de uma transformação sobre a informação espacial restante ou
seja, MPEG é um código de vídeo híbrido DPCM/DCT. O diagrama de blocos de um sistema de
codificação e decodificação de vídeo MPEG é mostrado na Figura 4.
Figura 4: Modelo da parte de vídeo de um sistema MPEG
A seguir será mostrado em detalhes cada passo de um algoritmo de codificação MPEG, mostrando
quando necessário alguns trechos de código em C.
3.1.1 Espaço de Cores e Subamostragem
Um grande espectro de cores pode ser representado por um conjunto de três cores primárias. O
espaço de cores obtido através da combinação de três cores pode ser determinado desenhando-se
um triângulo em um mapa de cores clássico onde cada extremidade é uma cor. Em geral as imagens
são representadas pelas três subtrativas primárias: vermelho, verde e azul. Este espaço de cores é
conhecido como RGB (Red, Green and Blue). Um espaço, usado em alguns padrões de televisão
(PAL, SECAM) é o YUV ou YCbCr. Neste espaço, Y é uma componente de luminância e U ou Cb,
V ou Cr são componentes de crominância.
Pesquisas no sistema visual humano mostraram que o olho é mais sensível a mudanças de
luminância e menos sensível a variações de crominância. Como o objetivo é compressão, faz
sentido que a codificação MPEG opere em um espaço de cores onde seja possível tirar vantagem
32
desta propriedade da visão. Por isso, MPEG usa o espaço YUV para representar as imagens ao
invés do tradicional RGB.
Então, os algoritmos MPEG primeiro dividem as imagens em suas componentes YUV e depois faz
uma subamostragem das componentes de crominância em relação à componente de luminância. O
conceito básico de subamostragem é reduzir a dimensão da entrada de vídeo. No decodificador os
dados são recuperados através de interpolação.
Os algoritmos MPEG dividem a imagem em blocos e macroblocos. Cada bloco é uma matriz de
8x8 pixels e os macroblocos podem ser representados de várias maneiras diferentes de acordo com
a taxa usada para fazer a subamostragem. Na Figura 5 são mostrados alguns formatos. No formato
4:4:4, que é completo, cada macrobloco é constituído por 4 blocos Y, 4 blocos U e 4 blocos V. O
formato 4:2:0 fornece redução imediata de 12 blocos/macroblocos para 6 blocos/macroblocos ou
2:1 comparado com a representação 4:4:4 ou RGB. O padrão MPEG-1 usa a representação 4:2:0
enquanto que o MPEG-2 trabalha com as representações 4:2:0, 4:2:2 e 4:4:4 dependendo do perfil
usado.
Figura 5: Macroblocos do padrão MPEG
33
3.1.2 Estimação e Compensação de Movimento
Predição por compensação de movimento é uma poderosa ferramenta para reduzir redundâncias
temporais entre quadros e é usado extensivamente nos padrões MPEG como uma técnica de
predição para codificação DPCM temporal. Desde que a maioria dos quadros de uma seqüência de
imagens se parecem muito similares exceto por deslocamentos devido a movimentos como os da
lente de uma câmera através de um cenário, nos é permitido codificar um quadro através do cálculo
do vetor de deslocamento em relação a imagem anterior. No caso do MPEG as imagens são
separadas em macroblocos de 16x16 pixels e apenas um vetor de movimento é estimado, codificado
e transmitido para cada um destes blocos. O erro de estimação, ou seja, a diferença entre um quadro
e sua estimação também é transmitido.
A Figura 6 retirada de [19] mostra as vantagens do uso da predição de movimento compensado. A
Figura 6(a) é um quadro a ser codificado no instante N e Figura 6(b) é o quadro no instante anterior
que estava armazenado tanto no codificador como no decodificador. Os vetores de movimento de
cada macrobloco, que também estão mostrados na Figura 6(b), mostram o deslocamento médio de
cada macrobloco no instante N em relação ao instante N-1. A Figura 6(c) mostra uma diferença
pura entre os quadros, ou seja, o vetor de movimento é considerado nulo. A Figura 6(d) mostra o
erro de predição entre os quadros considerando o vetor de movimento. Por estas figuras, é claro que
sinal residual a ser codificado é muito reduzido usando compensação de movimento se comparado a
simples diferença entre quadros.
34
(a)
(b)
(c)
(d)
Figura 6: Efeito do vetor de movimento compensado
Continuando esta analogia, é interessante considerar o futuro da mesma forma que o passado, e por
isso, a compensação/estimação de movimento MPEG considera os dois sentidos de tempo. Uma
seqüência típica MPEG consiste em três partes separadas: uma série de intraframes(I), que são
quadros de imagem codificados individualmente sem nenhuma predição temporal; uma série de
quadros preditos à frente (forward predicted frames - P) localizados entre os quadros-I ; e quadros
preditos bidirecionalmente (bidirectionally predicted frames - B) localizados entre os intraframes e
os forward predicted frames. Estes últimos podem ser considerados como uma interpolação de
movimento compensado entre os quadros-I e os quadros-P. Isto é mostrado na Figura 7. O quadro-I
é codificado primeiro seguido do próximo quadro-P e dos quadros-B. O processo se repete com o
próximo quadro-P e quadro-B e assim por diante.
35
Figura 7: Modelo MPEG de compensação de movimento
O usuário pode escolher o tipo de arranjo a ser usado em uma codificação de acordo com a
aplicação desejada. Em geral uma seqüência usando somente quadros-I (IIIIII...) permite uma alto
grau de acesso aleatório e editabilidade mas possui pouca compressão. Uma seqüência do tipo
(IPPPIPPPI...) possui compressão moderada e um certo grau de acesso aleatório. Usando seqüências
do tipo (IBBPBBPBBPBBI...) temos alta taxa de compressão e um razoável acesso aleatório mas
aumentamos o tempo de codificação e decodificação o que em algumas aplicações não é permitido.
No padrão MPEG-2 onde é possível o uso de imagens entrelaçadas foram desenvolvidas novas
técnicas de predição. Em imagens entrelaçadas cada quadro é composto de dois campos: um
contendo as linhas impares e o outro contendo as linhas pares. Em uma das novas técnicas os
campos são calculados usando-se os dois últimos campos, não importando se eles são pares ou
impares. O Código abaixo é um trecho de programa usado para calcular os quadros-P e o erro de
predição. Note que é possível escolher quantos quadros são preditos entre um quadro-I,
representado por FFS[0], através da variável FrameInterval.
36
/* Do first forward predictive frame */
for(i=2;i<=FrameInterval;i++)
{
MaxX = MaxY = (i<<3)-1;
MinX = MinY = -(i<<3);
BMaxX = BMaxY = (i<<4)-1;
BMinX = BMinY = -(i<<4);
for(n=0,y=0;y<FFS[0]->height;y+=16) /* Doing Forward */
{
for(rx=ry=dx=dy=x=0;x<FFS[0]->width;x+=16)
{
CircleLimit = SearchLimit + MAX(rx,ry)+1;
/* HPFastBME() does a fast brute-force motion estimation with
two indexes into two memory structures. */
HPFastBME(x,y,FFS[0],x,y,FFS[i],dx/2,dy/2);
FMX[i][n] = MX; /* MX and MY contain the integer mc vectors.*/
FMY[i][n] = MY;
dx = MX-FMX[i-1][n]+FMX[i-1][n+1]; /* Next pos */
dy = MY-FMY[i-1][n]+FMY[i-1][n+1]; /* next pos */
if (dx < BMinX) dx = BMinX;
else if (dx > MaxX) dx = BMaxX;
if (dy < BMinY) dy = BMinY;
else if (dy > MaxY) dy = BMaxY;
rx = abs(dx - FMX[i-1][n+1]); /* Distance from 0pred */
ry = abs(dy - FMY[i-1][n+1]);
n++;
}
}
}
3.1.3 Transformada Discreta de Cosenos
Se a energia de vídeo da imagem é de baixa freqüência espacial, ou seja, varia lentamente no
espaço, então uma transformada pode ser usada para concentrar a energia em poucos coeficientes. O
estágio DCT (Discrete Cosine Transform) da Figura 8 é aplicado tanto nos intraframes como nas
imagens que representam os erros de predição calculados tratados na seção anterior. Para
simplificar a complexidade da transformada, a imagem é dividida em pequenos blocos de 8x8
pixels onde é aplicada uma DCT bidimensional.
A transformada de cosenos bidimensional pode ser obtida através do cálculo da transformada
unidimensional nas colunas e a transformada unidimensional nas linhas. Uma fórmula explicita para
a transformada de cosenos bidimensional 8x8 pode ser escrita em termos dos valores dos pixels,
f(i,j), e os coeficientes no domínio da freqüência, F(u,v).
37
F(u,v) = 1
4
C(u)C(v)
7
∑ i = 0
7
∑ j = 0
f(i,j)cos( (2i+1)uπ
16
) cos( (2j+1)vπ
16
) ,
onde
C(x) =
1/√2 x = 0
1 x ≠ 0
.
A saída transformada da DCT bidimensional é ordenada de forma que o valor médio, ou coeficiente
DC, está no canto superior esquerdo e os coeficientes de altas freqüências aumentam com a
distância ao coeficiente DC. As altas freqüências verticais são representados por índices grandes
para as linhas e as altas freqüências horizontais são representados por índices grandes para as
colunas.
A transformada de cosenos inversa pode ser escrita como:
f(i,j) = 1
4
7
∑ u = 0
7
∑ v = 0
C(u)C(v)F(u,v)cos( (2i+1)uπ
16
) cos( (2j+1)vπ
16
) .
Como a Transformada Discreta de Cosenos é uma transformação unitária, o valor máximo de cada
um dos 64 coeficientes da DCT é limitado a um fator de oito vezes o valor original.
3.1.4 Quantização
Os coeficientes da DCT são quantizados para reduzir sua amplitude e aumentar o número de
coeficientes iguais a zero descartando informações que são visualmente insignificantes. Uma
quantização uniforme é usada nos algoritmos MPEG, com um degrau de tamanho diferente de
acordo com a posição do coeficiente. Os blocos dos intraframes são quantizados com os termos DC
e AC separadamente. Esta quantização é mostrada nas Equações e respectivamente.
C(0,0) = (F(0,0) ±4) / 8 (1)
C(u,v) = ((A(u,v) ±QF)/ 2QF (2)
onde:
38
A(u,v) = ((F(u,v) * 16) ±Q(u,v)/2) / Q(u,v)
Nas Equações 1 e 2 C(u,v) é o coeficiente quantizado, F(u,v) é o coeficiente DCT, Q(u,v) é o
tamanho do degrau, QF é o parâmetro de quantização (usado para controle de taxa) e ± é positivo
para F(u,v) positivo e negativo para F(u,v) negativo. A quantização inversa é dada por:
F(0,0) = 8 C(0,0) (3)
F(u,v) = C(u,v) QF Q(u,v)/8 (4)
Para os blocos preditos e interpolados, o quantizador tem uma zona morta ao redor do zero e é o
mesmo para os coeficientes DC e AC.
A(u,v) = ((F(u,v) * 16) ±Q(u,v)/2) / Q(u,v) (5)
Se QF é impar:
C(u,v) = A(u,v)/ 2QF (6)
e se QF é par:
C(u,v) = (A(u,v)±1)/ 2QF (7)
onde ± é positivo para A(u,v) > 0 positivo e negativo para A(u,v) < 0. A quantização inversa é então:
F(u,v) = (2F(u,v) ±1) QF Q(u,v)/16 (8)
onde ± é positivo para F(u,v) > 0 positivo e negativo para F(u,v) < 0.
A quantização é o estágio de perdas na codificação MPEG ( o estágio de DCT também produz
perdas mas em escala muito menor). O Código seguinte mostra duas funções implementadas em C
para fazer a quantização dos coeficientes da DCT.
39
void MPEGIntraQuantize(matrix,qptr,qfact)
int *matrix;
int *qptr;
int qfact;
{
int *mptr;
int qp;
qp = qfact << 1;
mptr = matrix;
if (*mptr>0)
*mptr=(*mptr + 4)/8;
else
*mptr=(*mptr - 4)/8;
for(qptr++,mptr++;mptr<matrix+BLOCKSIZE;mptr++,qptr++)
{
if (*mptr>0)
{
*mptr = ((*mptr << 4) + (*qptr >> 1)) / *qptr;
*mptr = (*mptr + qfact) / qp;
}
else if (*mptr < 0)
{
*mptr = ((*mptr << 4) - (*qptr >> 1)) / *qptr;
*mptr = (*mptr - qfact) / qp;
}
}
}
void MPEGNonIntraQuantize(matrix,qptr,qfact)
int *matrix;
int *qptr;
int qfact;
{
int *mptr;
int qp = qfact<<1;
for(mptr=matrix;mptr<matrix+BLOCKSIZE;mptr++,qptr++)
{
if (*mptr>0)
{
*mptr = ((*mptr << 4) + (*qptr >> 1)) / *qptr;
if (qfact&1)
*mptr = (*mptr)/qp;
else
*mptr = (*mptr+1)/qp;
}
else if (*mptr < 0)
{
*mptr = ((*mptr << 4) - (*qptr >> 1)) / *qptr;
if (qfact&1)
*mptr = (*mptr)/qp;
else
*mptr = (*mptr-1)/qp;
}
}
}
40
Nestas funções qptr é uma das matrizes mostradas no código seguinte:
int MPEGIntraQ[] =
{8, 16, 19, 22, 26, 27, 29, 34,
16, 16, 22, 24, 27, 29, 34, 37,
19, 22, 26, 27, 29, 34, 34, 38,
22, 22, 26, 27, 29, 34, 37, 40,
22, 26, 27, 29, 32, 35, 40, 48,
26, 27, 29, 32, 35, 40, 48, 58,
26, 27, 29, 34, 38, 46, 56, 69,
27, 29, 35, 38, 46, 56, 69, 83};
int MPEGNonIntraQ[] =
{16, 16, 16, 16, 16, 16, 16, 16,
16, 16, 16, 16, 16, 16, 16, 16,
16, 16, 16, 16, 16, 16, 16, 16,
16, 16, 16, 16, 16, 16, 16, 16,
16, 16, 16, 16, 16, 16, 16, 16,
16, 16, 16, 16, 16, 16, 16, 16,
16, 16, 16, 16, 16, 16, 16, 16,
16, 16, 16, 16, 16, 16, 16, 16};
3.1.5 Codificação
A etapa de codificação é dividida em duas partes. Na primeira é feita um rearranjo da disposição
dos valores a serem codificados e na segunda é feita a codificação propriamente dita.
Os coeficientes DCT quantizados são rearranjados em um padrão ``zig-zag'' com as baixas
freqüências seguidas das altas freqüências. Este padrão é usado para aumentar o número de
coeficientes iguais a zero consecutivos em cada bloco. É assumido que as baixas freqüências
tendem a ter coeficientes maiores e as altas freqüências são, pela natureza da maioria das imagens,
predominantemente zero. Como é mostrado na Figura 8, os coeficientes AC são escaneados através
de um zig-zag, da localização (0,1) à localização (7,7).
41
Figura 8: O padrão zig-zag para transformar o coeficientes DCT em um vetor unidimensional
Os coeficientes DC quantizados são codificados pelo número de bits significativos, seguido pelos
próprios bits. Os coeficientes AC usualmente contêm séries de zeros consecutivos. Por isso, podem
ser obtidas vantagens se esta característica for explorada através de técnicas de codificação
adequadas. Estes coeficientes são então codificados baseado no número de zeros consecutivos entre
dois coeficientes não-zero. Como freqüentemente ocorrem combinações iguais de zeros
consecutivos e coeficientes não-zero um código de tamanho variável, como o Código de Huffman,
pode ser usado.
O Código de Huffman é um código de compressão baseado na entropia dos dados a serem
codificados. Para comprimir os dados, os mesmos são divididos em tabelas de símbolos e são
criados códigos para cada símbolo. O codificador cria então, códigos pequenos para os símbolos
que ocorrem com maior freqüência e códigos maiores para aqueles que ocorrem ocasionalmente. Na
verdade o codificador MPEG usa tabelas estáticas como aquela mostrada no Código anterior. Na
primeira coluna estão os símbolos em hexadecimal e na segunda o código binário usado para
codificá-los. Mais informações sobre o código de Huffman e demais técnicas de compressão e
compactação podem ser encontradas em [2].
42
3.2 Resumo do Algoritmo Em geral os algoritmos de codificação MPEG podem ser modelados como mostrado na Figura 9. O
primeiro quadro da seqüência de vídeo (intraframe) é codificado sem referência a nenhum quadro
passado ou futuro (Seção 3.1.2). É aplicada a transformada discreta de cosenos (Seção 3.1.3) a cada
bloco 8x8 de luminância e crominância (Seção 3.1.1). Depois disso, cada um dos 64 coeficientes da
DCT são uniformemente quantizados (Seção 3.1.4) e codificados (Seção 3.1.5). Nesta etapa o
coeficiente DC sofre um tratamento especial em relação aos componentes AC. Os quadros seguintes
são separados em quadros-P e quadros-B (Seção 3.1.2). Para os quadros-P o último quadro-I ou -P é
armazenado, e é estimado um vetor de movimento para cada macrobloco. Este vetor é codificado,
agrupado ao erro de predição calculado e já codificado como um quadro-I e transmitido em um
fluxo de bits. Para quadros-B um quadro é interpolado entre um quadro anterior e um quadro futuro
e o erro entre ele e o quadro original é codificado como um quadro-I.
Figura 9: Diagrama de blocos do codificador
O algoritmo de decodificação é simples. Primeiro é feita a quantização inversa, seguido da
transformada inversa e da compensação com o uso do vetor de movimento e das imagens
previamente reconstruídas.
3.3 Técnicas de compactação
3.3.1 Compactação pela DCT A compactação proveniente do estágio de DCT está diretamente relacionada às características da
imagem a ser codificada. O objetivo maior deste estágio é obter coeficientes suficientemente
pequenos para serem desprezados no estágio de quantização. Por isso as imagens com variação
43
espacial mais lenta terão uma compressão maior do que aquelas com variação mais rápida. As
imagens da Figura 10 foram codificadas em MPEG separadamente usando as características default
do codificador. O resultado pode ser visto na Tabela 1. Apesar de ambas as imagens possuírem uma
alta taxa de compressão o arquivo MPEG obtido para a segunda imagem é 90% maior que aquele
obtido para a primeira com baixas freqüências espaciais..
(a)
(b)
Figura 10: Comparação entre duas imagens com os mesmos tons cinza mas com variação espacial diferente
Tamanho da Imagem Tamanho da Imagem Taxa de
Imagem Original (.ppm) Codificada (.mpg) Compressão
(a) 172.815 bytes 1.945 bytes 98,88%
(b) 172.815 bytes 3.723 bytes 97,85% Tabela 1: Efeito da presença de altas freqüências espaciais na imagem
3.3.2 Compactação no estágio de quantização A quantização está diretamente relacionada com o controle da taxa de transmissão e
consequentemente com o tamanho do arquivo gerado. Como foi mostrado na seção anterior, este
estágio também depende das características da imagem. Desta forma, imagens com baixas
freqüências espaciais podem ser mais comprimidas através da escolha de um degrau de quantização
maior, gerando vídeos com pouca variação de qualidade. Já as imagens com altas freqüências
44
exigem degraus menores para manterem a qualidade do vídeo. A curva da Figura 11 foi obtida
variando-se o parâmetro de quantização QF das Equações 2 à 8 e medindo-se a taxa de compressão
em relação à QF = 1. Esta curva foi obtida com a codificação de 60 quadros do filme “O
Exterminado do Futuro II” com padrão NSTC de 352x240 pixels. Como já foi mencionado, esta
curva é altamente dependente das características do vídeo a ser codificado.
A Figura 12 mostra um dos quadros codificados. A imagem da Figura 12 (a) foi quantizada com QF
= 8 (valor default) e a da Figura 12 (b) foi quantizada com QF = 23. Note que na Figura 12 (b)
temos uma deterioração significativa da imagem codificada.
Figura 11: Taxa de compressão em função do Parâmetro de Quantização
45
(a)
(b)
Figura 12: Comparação entre duas imagens com graus de quantização diferentes
3.3.3 Compactação por compensação de Movimento Como já foi mencionado, é possível escolher a configuração, ou seja, a quantidade de quadros-I, -P
e -B em um vídeo MPEG. Como será visto adiante, o protocolo MMTP utiliza este tipo de
compactação priorizando os quadros a serem transmitidos.
No primeiro exemplo as imagens da Figura 13 foram usadas como base para geração de vídeos
MPEG. No primeiro vídeo gerado foram usados apenas quadros-I, ou seja não houve compensação
de movimento. Este vídeo foi gerado por quadros iguais ao da Figura 13 (a). Um segundo vídeo foi
gerado usando-se as mesmas imagens só que agora usando 5 quadros-P entre os quadros -I. No
terceiro e último também foram usados 5 quadros-P mas desta vez a seqüência de imagens foi
formada pela imagem da Figura 13(a) seguida pela sua imagem espelhada (Figura 13(b)). Todos os
vídeos eram formados por 10 quadros. O tamanho dos arquivos e as taxas de compressão obtidas
podem ser vistos na Tabela 2.
46
(a)
(b)
Figura 13: Imagens espelhadas usadas no teste de compensação de movimento
Vídeo Tamanho do Vídeo Compressão
somente quadros-I 136.516 bytes 0%
10 quadros iguais 38.004 bytes 72,2%
quadros espelhados 147.837 bytes -8,3%
intercalados
Tabela 2: Efeito da semelhança entre as imagens na compactação
Em um segundo experimento, 120 quadros de 240x120 cada qual contendo um fundo branco e um
quadrado cinza de 20x20 pixels foram gerados a partir de um programa. Dois vídeos com 5
quadros-P entre os quadros-I foram então gravados. No primeiro os quadros foram colocados em
seqüência de tal forma que os quadrados se superpusessem de um quadro para o outro dando a
impressão de um movimento contínuo. No segundo vídeo os quadros foram alternados de forma
aleatória. Como resultado, foi observado que o vídeo contendo imagens seqüenciais teve uma
compressão de 47,09% (em relação a um vídeo somente com intraframes) e aquele contendo
imagens aleatórias teve uma compressão de 43,58%.
47
Em outro teste, foi usado o mesmo vídeo da Seção 3.3.2 com variações nas seqüências de quadros.
Os gráficos da Figura 14 mostram os resultados deste teste. A Figura 14(a) foi obtida variando-se o
número de quadros-P entre os quadros-I e mantendo o número de quadros-B igual a zero (ex: 3
quadros-P ⇒ IPPPIPPPI...). A taxa de compressão é calculada em relação ao vídeo somente com
intraframes que ocupou 666.686 bytes. Vemos que a curva tem um crescimento rápido inicial, mas
tende a se estabilizar a medida que o número de quadros-P aumenta. Na Figura 14(b) o mesmo teste
foi feito, porém agora o número de quadros-P foi mantido igual a zero e foi variado o número de
quadros-B entre os intraframes (ex: 3 quadros-B ⇒ IBBBIBBBI...). Neste caso vemos que a curva
possui um ponto de máximo, ou seja, em certo momento, quando aumentamos o número de
quadros-B temos uma redução da taxa de compressão.
Na Figura 14(c) são mostrados os resultados obtidos quando temos um número fixo de quadros-P e
variamos o número de quadros-B. O caso contrário é mostrado na Figura 14(d). A configuração
para os vídeos gravados é então do tipo IBBPBBPBBIBBP... (2 quadros-P e 2 quadros-B).
(a)
(b)
48
(c)
(d)
Figura 14: Gráficos de compressão em função da configuração
3.4 Comparação das Técnicas e Conclusões Como foi visto neste capítulo, os algoritmos usam vários artifícios matemáticos para executar de
forma eficiente a compressão de seqüências de imagens ou vídeos. Os resultados do Capítulo 3.3
mostraram algumas características, principalmente em relação à compressão, dos algoritmos
MPEG.
Na Seção 3.3.1 mostramos como o desempenho do estágio de DCT depende da natureza das
imagens. Logicamente se pensarmos neste estágio como um sistema isolado, não fazemos
compressão alguma pois a aplicação da transformada a cada bloco de 8x8 pixels da imagem gera
uma outra matriz de coeficientes com as mesmas dimensões. A idéia principal deste estágio é então,
concentrar a informação em poucos coeficientes para que aqueles com baixa amplitude sejam
desprezados no estágio de quantização. Isto pôde ser comprovado com os experimentos feitos. A
primeira imagem foi gerada artificialmente com o objetivo de conter apenas baixas freqüências e
por isso obteve uma compactação de aproximadamente 50% em relação àquela contendo altas
freqüências. Como as imagens tinham as mesmas características em relação a dimensão e cores e a
quantização usada pelo algoritmo foi a mesma, podemos concluir que a distribuição dos
coeficientes da DCT foi responsável pela diminuição do número de bytes armazenados.
49
O estágio de quantização do algoritmo MPEG é o único onde temos perdas significativas da
informação armazenada. Apesar disso, esta perda é controlada de acordo com a compactação
desejada ou com a taxa de bits requerida. Isto significa que se tivermos uma taxa de transmissão
fixa, a única coisa que podemos fazer para controlar esta taxa é alterar a quantização. Quando
informamos a um codificador MPEG qual a taxa de bits a ser usada, o algoritmo calcula o fator de
quantização QF das Equações 2 à 8. Como não estamos trabalhando com taxas de transmissão
alteramos diretamente o fator QF e obtivemos a curva da Figura 11 a partir de um dado vídeo. É
claro que esta curva é fortemente dependente das imagens a serem codificadas pois ela está
diretamente relacionada com a distribuição de freqüências espaciais da imagens. Apesar disso,
podemos ter um idéia do efeito da quantização. Vemos que é possível obter compactações
surpreendentes pois mesmo tendo perdido um pouco a qualidade do vídeo foi possível compactar
em 90% um vídeo no formato NTSC. Nota-se também que apenas aumentado um pouco a
quantização podemos obter altas taxas de compressão e consequentemente baixas taxas transmissão
de bits.
Os últimos exemplos, mostrados na Seção 3.3.3, verificam a eficiência do estágio que realmente
difere o padrão MPEG dos padrões de compactação de uma única imagem como o JPEG. Um
primeiro teste, onde foram usadas imagens iguais em um vídeo e imagens espelhadas em outro,
mostrou que dependendo da situação, podemos ter um arquivo que usa predição, maior do aquele
gerado sem predição. Isto ocorre porque o erro de predição contem muita informação (quase ou a
mesma quantidade contida na imagem original) e como temos que armazenar (transmitir) também o
vetor de predição para cada macrobloco, ao invés de diminuir, aumentamos a quantidade de bytes
no arquivo. É claro que na maioria das vezes não temos esta situação pois os vídeos, em geral,
possuem variações lentas de um quadro para o outro. Na prática podemos ter quadros
completamente diferentes dos seguintes (nas mudanças de cenas dos filmes, por exemplo), mas que
ocorrem com menos freqüência que as séries de quadros parecidos ou iguais.
No último exemplo, um vídeo no formato NTSC foi decodificado e codificado de várias formas
diferentes. Novamente, sabemos que os resultados obtidos não seriam idênticos se fossem usados s
vídeos diferentes, mas, como se trata de um vídeo com características comuns, podemos ter idéia de
como é o comportamento do decodificador. No primeiro gráfico da Figura 14 vemos que
aumentando o número de quadros-P sempre conseguimos reduzir o tamanho do arquivo mesmo que
haja uma saturação a medida que este número cresce. Esta saturação ocorre porque o número de
quadros-I (que são os quadros que gastam mais espaço de memória) passa a diminuir com uma taxa
50
menor. Por exemplo: no nosso vídeo temos 60 quadros; quando codificamos somente com
intraframes temos 60 quadros-I, valor que passa para 30 se codificarmos com 2 quadros-P, ou seja,
uma redução de 30 quadros; quando usamos 20 quadros preditos temos 3 quadros-I, apenas 1 a mais
do que se usarmos 30 quadros-P.
Na Figura 14(b) vemos que temos o mesmo efeito da situação anterior e ainda uma diminuição da
taxa de compressão a medida que o número de quadros-B aumenta. Isto acontece porque a medida
que o número de quadros-B aumenta, aumenta também a distância temporal entre os quadros-I.
Como os quadros-B são interpolados entre dois quadros-I (porque não existem quadros-P) quanto
mais longe estes estiverem um do outro maior será o erro de interpolação e consequentemente
teríamos maior quantidade de informação a ser armazenada. A Figura 14(c) mostra a mesma
tendência mas como temos a presença de quadros-P a distância entre os quadros entre os quais se
faz a interpolação é menor e por isso a queda na taxa de compressão tende a ser menor. Apesar de
termos aumentado a taxa de compressão, os resultados dos gráficos da Figura 14(d) são muito
próximos daqueles mostrados na Figura 14(a).
Fazendo uma comparação entre os gráficos da Figura 14 percebemos que a configuração contendo
10 quadros-B e nenhum quadro-P foi a que apresentou maior compactação. Isto se deve ao fato de
as imagens serem muito semelhantes, causando um erro de interpolação pequeno, e não haver a
necessidade do uso de vetores de movimento para representação da imagem. Quando temos o
arquivo MPEG armazenado localmente, sem dúvida, esta seria uma boa escolha de configuração
para este vídeo em particular. O problema seria se estivéssemos trabalhando com transmissão em
tempo real. Neste caso o receptor deveria armazenar 10 quadros (contendo os erros de interpolação)
até que recebesse o próximo quadro-I para então calcular as imagens finais. Teríamos problema
também se precisássemos evoluir o vídeo quadro a quadro. Nesta situação com certeza os quadros
do vídeo contendo somente quadros-I seriam mostrados mais rapidamente que aqueles do vídeo
contendo quadros interpolados. De qualquer forma, vemos que o algoritmo nos permite uma grande
gama de opções e a escolha deve ser feita de acordo com as nossas aplicações. Para uma aplicação
comum como a de deixar pequenos vídeos em um site de FTP, por exemplo, uma boa escolha de
configuração seria a de 2 quadros-P e 2 quadros-B entre eles o que no nosso caso proporcionou um
compactação de 60% em relação ao vídeo somente com quadros-I. Note que este último já
apresenta uma grande compactação devido às etapas de DCT, quantização e codificação.
Por tudo o que foi falado podemos concluir que MPEG-1 e MPEG-2 são padrões de codificação
muito versáteis e ideais para aplicações onde são necessários níveis de compactação razoáveis para
51
seqüências de imagens. Entre estas aplicações as mais difundidas hoje em dia são o vídeo em CD e
a televisão digital. Em outras aplicações, como vídeo conferência por exemplo, onde são desejáveis
taxas de compressão muito altas, estes padrões não são muito aplicáveis. É o caso por exemplo do
experimento do quadrado se movendo em um fundo branco que equivale a uma pessoa falando em
um fundo estático. Como cada imagem é considerada como tal sem preocupação com o conteúdo,
de uma forma ou de outra sempre devemos transmitir informação sobre o fundo.
52
Capítulo 4
4. O projeto do player de Berkeley
O mpeg_play é um software de domínio público, para decodificação e exibição de video MPEG-1
em sistemas gráficos X113. Criado por Lawrence A. Rowe, Ketan Patel, Brian Smith, Steve Smoot,
e Eugene Hung, da Divisão de Ciência da Computação da Universidade de Berkeley, na California
(EUA), o player decodifica somente fluxos de vídeo, mas é capaz de tratar fluxos MPEG
multiplexados (video+audio),identificando os fluxos de vídeo e descartando os de audio.
O decodificador implementa o padrão descrito no Committee Draft ISO/IEC CD 11172 (6 de
Dezembro, 1991) que é também referido como “Paris Format”.
A decodificação e exibição do vídeo se dá através de uma enorme e organizada estrutura de dados,
denominada vid_stream, que é utilizada em todo o programa e definida abaixo:
/* Video stream structure. */
typedef struct vid_stream {
unsigned int h_size; // Horiz. size in pixels.
unsigned int v_size; // Vert. size in pixels.
unsigned int mb_height; // Vert. size in mblocks.
unsigned int mb_width; // Horiz. size in mblocks.
unsigned char aspect_ratio; // Code for aspect ratio.
unsigned char picture_rate; // Code for picture rate.
unsigned int bit_rate; // Bit rate.
unsigned int vbv_buffer_size; // Minimum buffer size.
BOOLEAN const_param_flag; // Contrained parameter flag.
unsigned char intra_quant_matrix[8][8]; // Quantization matrix for
// intracoded frames.
unsigned char non_intra_quant_matrix[8][8]; // Quanitization matrix for
//non intracoded frames.
char *ext_data; // Extension data.
char *user_data; // User data.
GoP group; // Current group of pict.
Pict picture; // Current picture.
Slice slice; // Current slice.
Macroblock mblock; // Current macroblock.
Block block; // Current block.
int state; // State of decoding.
int bit_offset; // Bit offset in stream.
unsigned int *buffer; // Pointer to next byte in buffer.
int buf_length; // Length of remaining buffer.
3 X11 – XFree86, fornece uma interface cliente/servidor entre o hardware a nível de usuário (mouse, teclado e monitor de video) e o ambiente do desktop, provendo também a estrutura de janelas e a aplicação padrão de interface (API).
53
unsigned int *buf_start; // Pointer to buffer start.
/* Brown - beginning of added variables that used to be static or global */
int max_buf_length; // Max length of buffer.
int film_has_ended; // Boolean - film has ended
int sys_layer; // -1 uninitialized,
// 0 video layer,
// 1 syslayer
unsigned int num_left; // from ReadPacket - leftover
unsigned int leftover_bytes; // from ReadPacket - leftover
int EOF_flag; // stream is EOF
FILE *input; // stream comes from here
long seekValue; // 0 no seeking
// >0 do a seek,
// <0 already has done seek
BOOLEAN swap; // from ReadFile
BOOLEAN Parse_done; // from read_sys
int gAudioStreamID;
int gVideoStreamID;
int gReservedStreamID;
int right_for,down_for; // From ReconPMBlock, video.c
int right_half_for, down_half_for;
unsigned int curBits; // current bits
int matched_depth; // depth of displayed movie
char *filename; // Name of stream filename
int ditherType; // What type of dithering
char *ditherFlags; // flags for MB Ordered dither
int totNumFrames; // Total Number of Frames
double realTimeStart; // When did the movie start?
/* Brown - end of added variables */
PictImage *past; // Past predictive frame.
PictImage *future; // Future predictive frame.
PictImage *current; // Current frame.
PictImage *ring[RING_BUF_SIZE]; // Ring buffer of frames.
/* x,y size of PPM output file */
int ppm_width, ppm_height, ppm_modulus;
} VidStream;
É através dessa importante estrutura, que o programa mantém o controle das configurações de
exibição e dos fluxos de vídeo em processo de decodificação na memória.
Após inicializada a estrutura vid_stream, seu buffer de memória é carregado com parte do fluxo de
vídeo pela função get_more_data, lendo diretamento do arquivo mpeg armazenado. Esse fluxo de
bits é, então, analisado pela função mpegVidRsrc, que chama funções de decodificação
apropriadas para cada GOP, quadro, slice ou bloco do fluxo MPEG. O mpegVidRsrc prossegue
com seu trabalho até que tenha encontrado e decodificado um determinado número de macroblocos,
ou que o slice atual ou quadro chegue ao fim. Os quadros encontrados ganham uma marcação de
54
tempo e após a decodificação são encaminhados para a fila de exibição onde serão também
analisados quanto a suas dependências em relação a outros quadros.
Antes de qualquer operação de decodificação, o programa sempre verifica se existem bytes
suficientes no buffer de memória do vid_stream. Se for necessário, a função correct_underflow é
executada, preenchendo o buffer com o auxílio da função pure_get_more_data (para simples
fluxos de vídeo) ou read_sys (para fluxos multiplexados com audio). Assim, os dados são lidos do
arquivo mpeg e os ponteiros de controle da estrutura vid_stream são atualizados de acordo.
Todas as funções mencionandas podem ser encontradas nos arquivos fontes do mpeg_play como mostrado a seguir:
• A estrutura principal vid_stream e várias outras estruturas e constantes estão em video.h
• O mpegVidRsrc e outras principais chamadas de decodificação e parsing estão em video.c
• Para decodificações de macroblocos e DCTs são chamadas funções de parseblock.c e
decoder.c
• Funções utilitárias como o correct_underflow estão em util.c
• get_more_data, read_sys e outras funções para leitura e tratamento de arquivos em disco
aparecem em readfile.c
55
Capítulo 5
5. Métodos mais usados na Transmissão de Vídeo
5.1 Métodos tradicionais
Inicialmente, o vídeo começou a ser distribuído através de dois métodos: “download” completo e
“download” progressivo [21]. No primeiro método, o conteúdo multimídia só começa a ser
reproduzido após todo o arquivo ter sido guardado numa unidade de armazenamento (disco rígido
por exemplo). Este método origina um grande atraso entre o instante em que é pedido o arquivo
multimídia e o instante em que este é reproduzido, atraso esse que aumenta se o arquivo pedido
ainda necessitar de ser produzido no emissor que o vai enviar (por exemplo um servidor). Como
conseqüência, este método só se torna realmente interessante para transmitir pequenos arquivos
para o usuário, e este último não pode ter limitações de capacidade de armazenamento, de conexão
com o servidor ou em caso limite … de paciência.
O segundo método descrito, o “download” progressivo, diferencia-se do primeiro apenas na
medida em que após uma determinada quantidade do conteúdo multimídia estar guardado no disco
do usuário, começa desde logo a ser reproduzida, enquanto a quantidade restante continua a ser
“descarregada”. Claro que isto só se torna possível se o índex do arquivo (que contém a informação
sobre o formato e o conteúdo) se localizar no início do mesmo e puder ser completamente guardado
no início do processo.
O download progressivo de arquivos pequenos é quase instantâneo, mas se os arquivos forem muito
grandes, a fase inicial do processo torna-se lenta, originado também um atraso entre o instante em
que o pedido é feito e o instante em que se começa a reproduzir.
Para transmitir vídeo já gravado num qualquer servidor, estas duas tecnologias ainda são
consideradas satisfatórias (o usuário pode esperar alguns segundos ou mesmo minutos até começar
a ver um filme sem mais interrupções). Mas para os novos conteúdos multimídia, onde se insere
56
mais uma vez o formato vídeo, como por exemplo uma teleconferência ou a transmissão de um jogo
de futebol ao vivo, é necessário não existir atraso ou esse se manter dentro de limites mínimos.
Torna-se assim claro que uma das características da distribuição destes conteúdos, ao contrário dos
serviços Internet tradicionais (HTTP - Hypertext Transfer Protocol, FTP - File Transfer Protocol,
DNS - Domain Name System) é a de ser sensível aos atrasos. A outra é ser tolerante a perda
ocasional de dados (se por exemplo na reprodução de um vídeo forem suprimidas uma ou outra
frame aleatoriamente, dependendo do frame rate (velocidade de reprodução) usado, as
conseqüências podem nem sequer ser observáveis.
Da necessidade da transmissão destes novos conteúdos, surge nos dias de hoje mais um método de
distribuição do vídeo na Internet, o streaming [22].
5.2 Métodos Recentes – Streaming
O streaming é o processo de envio de conteúdos multimídia para visualização em tempo real. Neste
processo a reprodução começa antes de se receber a totalidade do arquivo e logo após um curto
atraso que possibilita ao receptor armazenar apenas alguns dados.
A diferença entre o streaming e o “download” progressivo é que os dados streaming multimídia
são reproduzidos diretamente sem serem descarregados primeiro para um disco rígido. O processo
de streaming necessita no mínimo de duas aplicações: uma aplicação servidor que entrega os dados
a uma aplicação cliente que faz os pedidos.
O streaming pode ser originado a partir de fontes “ao vivo”, como por exemplo uma câmera ligada
a um computador-servidor. Para que a aplicação cliente possa interagir com o servidor, situação
necessária neste tipo de aplicações (para por exemplo poder pedir para se fazer zoom na imagem
captada pela câmera), o cliente envia para o servidor comandos de controle, enquanto que o último
envia os conteúdos multimídia para o cliente de acordo com os comandos de controle que recebe,
como se mostra na figura 15.
57
Figura 15 – Entrega de dados e controle entre Servidor/Cliente (extraído de [22]).
Neste tipo de processo, como os dados não são guardados em disco, uma vez que são
automaticamente reproduzidos assim que chegam à aplicação cliente, nenhuma cópia fica acessível
ao cliente, constituindo assim uma vantagem para os distribuidores de multimídia, que garantem os
copyright’s. Esta nova tecnologia encontra-se em grande desenvolvimento pelas potencialidades
visíveis, apresentando desde já muitas soluções paralelas, sendo por isso necessário dedicar um sub-
capítulo aos vários tipos de streaming existentes, para melhor se definir esses métodos.
5.3 Tipos de Streaming usados na Internet
Existem atualmente 3 classes de streaming: “Stored Audio and Video Streaming”, “Streaming of
Live Audio and Video” e “Real Time Interactive Audio and Video Streaming” [21].
5.3.1 Stored Audio and Video Streaming
Trata-se de uma classe de streaming em que os arquivos áudio ou vídeo comprimidos se encontram
já produzidos e guardados num servidor, prontos para serem enviados para o cliente. Temos como
exemplo desta classe, arquivos de música, arquivos vídeo ou um programa de televisão previamente
gravado. Podemos distinguir 3 características desta classe. Elas são: o “Stored Media”, o
“Streaming” propriamente dito e o “Continuous Playout”. O Stored Media diz respeito ao conteúdo
multimídia que foi antecipadamente gravado e guardado num servidor. Com este conteúdo é
possível ao cliente fazer “pause”, “rewind” ou “fast-forward” ao conteúdo. O atraso no cliente não
deve por isso ser superior a 10 segundos, caso contrário as respostas não serão aceitáveis. O
58
Streaming é o conceito já referido de começar o playout do arquivo de mídia, apenas alguns
segundos após o início da sua recepção, não precisando de esperar pela sua total recepção. Por fim,
o conceito de Continuous Playout está ligado ao fato de que quando o playout no cliente tem início,
a reprodução do arquivo deve ser feita com a mesma velocidade que foi usada na gravação, o que
obriga a que a transmissão dos dados respeite um dado atraso máximo: os dados devem ser
recebidos a tempo de poderem ser reproduzidos no cliente, caso contrário, são considerados inúteis.
Para esta classe de streaming, as limitações de uma ligação ponto-a-ponto TCP, como os atrasos,
são aceitáveis só até certo ponto. O fato dessas ligações não apresentarem perdas, não é vantajoso e
pode mesmo ser dispensável. Em resumo, para conteúdos de tempo real, é aceitável a perca de
alguns dados a favor da diminuição dos atrasos, que são altamente prejudiciais.
5.3.2 Streaming of Live Audio and Video
É a classe que se assemelha a uma transmissão de rádio ou de televisão, mas que tem lugar na
Internet. Como o áudio/vídeo ao vivo não está já gravado (ou seja, está a ser produzido no próprio
momento), o cliente não pode fazer “fast-forward” ao conteúdo. Contudo, se guardarmos
localmente no cliente os dados já recebidos (com autorização da entidade que produz a mídia é
possível a aplicação cliente ser desenvolvida nesse sentido – de realçar que por norma não é
possível guardar dados streaming), pode ser ativada uma condição de “pause” ou de “rewind”.
Neste tipo de transmissão podem existir muitos clientes recebendo o mesmo conteúdo
simultaneamente com a sua distribuição ocorrendo de duas formas:
a) unicast: é uma conexão ponto-a-ponto entre o cliente e o servidor, onde cada cliente recebe seu
próprio stream do servidor. Dessa forma, cada usuário conectado ao stream tem sua própria
conexão e os dados vêm diretamente do servidor;
b) multicast: ocorre quando o conteúdo é transmitido sobre uma rede com suporte à multicast, onde
todos os clientes na rede compartilham o mesmo stream. Assim, preserva-se largura de banda,
podendo ser extremamente útil para redes locais com baixa largura de banda.
59
5.3.3 Real Time Interactive Audio and Video Streaming
Esta classe permite às pessoas usarem o áudio/vídeo para comunicarem entre si em tempo real. A
interação de áudio em tempo real é normalmente designada por “Telefone IP”, pois do ponto de
vista do usuário, é semelhante ao tradicional circuito fechado do Serviço de Telefone Convencional.
Com a interação vídeo em tempo real, também designado vídeo-conferência, o usuário além de falar
também se pode mover a qualquer momento. Durante a conversa entre 2 usuários, o atraso entre o
instante em que um deles fala e o instante em que essa ação é captada pelo outro, deve ser inferior a
poucas centenas de milissegundos. Numa conversa por telefone na Internet, um atraso de 150
milissegundos não é perceptível pelo ouvido humano, de 150 a 400 milissegundos é razoavelmente
aceitável e para atrasos superiores é frustrante, senão completamente inaceitável, pois os usuários
teriam dificuldade de reagirem aos outros.
5.4 Streaming de vídeo na internet
De acordo com [25], a Internet não é naturalmente adequada à transmissão de informação em tempo
real. Para executar multimídia sobre a Internet, muitas questões precisam ser respondidas:
a) multimídia requer intenso tráfego de dados. O hardware atual não oferece largura de banda
suficiente;
b) aplicações multimídia estão geralmente relacionadas com multicast, ou seja, o mesmo fluxo de
dados, não múltiplas cópias, é enviado a um grupo de receptores. Por exemplo, uma transmissão de
vídeo ao vivo pode ser enviada a milhares de clientes. Os protocolos desenvolvidos para aplicações
multimídia precisam considerar o multicast para reduzir o tráfego;
c) o preço para agregar recursos de rede aos atualmente existentes torna-se impraticável. Aplicações
em tempo real requerem largura de banda, então, precisa haver alguns mecanismos para que essas
aplicações reservem os recursos necessários ao longo da rota de transmissão;
d) a Internet é uma rede de transmissão de pacotes que são encaminhados independentemente
através de redes compartilhadas. As tecnologias atuais não podem garantir que dados de tempo real
não irão encontrar seu destino sem serem desordenados. Alguns novos protocolos de transporte
60
precisam ser usados para garantir que os dados de áudio e vídeo sejam mostrados continuamente, na
ordem correta e em sincronismo;
e) é necessário que existam algumas operações padrão para as aplicações gerenciarem o transporte e
apresentação de dados multimídia.
Segundo [21], existem hoje inúmeras discussões sobre como a Internet poderia atuar para melhor
acomodar o tráfego multimídia com todas as suas implicações. Por um lado, alguns pesquisadores
argumentam que não é necessário fazer modificações nos serviços e protocolos atuais, mas sim,
adicionar mais largura de banda às conexões. Opostos a esse ponto de vista, outros defendem a idéia
que a adição de largura de banda pode ser dispendiosa e, em breve surgiriam novas aplicações
multimídia que consumiriam essa banda extra.
Enfocando outra abordagem, alguns pesquisadores aconselham mudanças fundamentais na Internet,
de forma que as aplicações possam reservar explicitamente largura de banda em uma conexão. Tais
estudiosos acreditam que, se as aplicações indicarem o tráfego que pretendem realizar durante a
comunicação, ao mesmo tempo em que a rede efetuar o policiamento dessas conexões a fim de
verificar seu consumo real, o aproveitamento de largura da banda existente será maior. Tais
mecanismos, quando combinados, requerem softwares novos e complexos nos hosts e roteadores,
assim como novos tipos de serviços.
5.5 Enviando multimídia de um servidor de streaming
para uma aplicação Uma das formas de fornecer vídeo pela Internet se dá através dos servidores de streaming, que
tratam de enviar sinais de vídeo para reprodutores de mídia. Este servidor pode ser proprietário,
como aqueles comercializados pela RealNetworks (Real Media Server) e Microsoft (Media Server)
ou um servidor de streaming de domínio público [21].
Com um servidor de streaming, áudio e vídeo podem ser enviados sobre UDP (preferencialmente,
em relação ao TCP) utilizando protocolos da camada de aplicação, mais adequados do que
streaming via servidor HTTP.
61
Esta arquitetura requer dois servidores, um servidor de HTTP para servir às páginas Web; e um
servidor de streaming, para servir aos arquivos de vídeo. Os dois servidores podem executar em um
mesmo sistema ou em dois sistemas distintos.
Uma simples arquitetura para servidor de streaming descreve os seguintes passos:
a) um navegador Web faz uma requisição HTTP para obter um arquivo de descrição da
apresentação, conhecido também por arquivo metafile.
b) o servidor Web retorna o arquivo utilizado ao navegador para identificar o reprodutor de mídia
adequado para exibir o vídeo;
c) o arquivo é repassado para o reprodutor contendo informações referentes à localização do vídeo
no servidor de streaming;
d) o reprodutor faz a requisição do arquivo diretamente ao servidor de streaming. A partir deste
momento, servidor e reprodutor interagem diretamente utilizando seus próprios protocolos e podem
permitir uma interação maior do usuário com o stream de vídeo.
A arquitetura cliente-servidor possui várias opções para a entrega do vídeo. Algumas delas são
descritas a seguir:
a) o vídeo é transportado sobre o UDP a uma taxa constante, igual àquela com que o receptor
apresenta o conteúdo (esta taxa é equivalente à taxa de codificação do vídeo);
b) similar à anterior, nesta opção o receptor atrasa a e xibição por 2-5 segundos para eliminar a
variação nos atrasos em pacotes do mesmo stream, que podem ocorrer em função da rede. Esta
tarefa é realizada pelo cliente, armazenando o vídeo recebido em um buffer. Uma vez que o cliente
guardou alguns segundos da mídia, ele começa a “descarregar” o buffer. Novamente, a taxa de
preenchimento do buffer é igual à taxa com que é descarregado, exceto na ocorrência da perda de
pacotes;
c) processo semelhante ao descrito, porém, neste caso, a mídia é transportada sobre o TCP. Como o
TCP retransmite pacotes perdidos, desta maneira pode-se oferecer uma qualidade melhor do que
62
com o UDP. Por outro lado, a taxa de preenchimento do buffer varia conforme a perda de pacotes, o
que pode ocasionar um esvaziamento do buffer, resultando indesejáveis pausas na exibição do vídeo
no cliente.
5.6 Problemas do Streaming causados pela Internet
Na seqüência da definição de streaming convém referir que se trata de uma tecnologia ainda
recente, e por isso ainda não é totalmente robusta, havendo muito por fazer e melhorar,
principalmente no que diz respeito a certas características da Internet que limitam o desempenho do
Streaming [21]. Este item identifica essas principais características e correspondentes ações que
devem se tomar para tornar o stream de dados mais eficaz e confiável.
Começa-se por diferenciar duas maneiras diferentes de fazer o streaming na Internet hoje em dia.
Uma delas é através de um Standard Web Server que seja capaz de servir conteúdos multimídia. É
uma solução semelhante ao “download” e “play” e a única diferença reside no funcionamento do
cliente. No entanto esta solução apresenta alguns problemas pois a aplicação servidor usa HTTP,
que não foi desenhado para transferir conteúdo mídia, operando apenas em cima do TCP. O TCP é
otimizado para aplicações que não de tempo real, como transferência de arquivos e logins remotos.
O seu objetivo é maximizar a transferência de dados conservando a estabilidade de toda a rede. Para
isso usa um algoritmo chamado “Slow Start” em que inicialmente envia os dados a uma freqüência
baixa, aumentando-a gradualmente até que sejam detectadas percas de pacotes. Ai, o TCP assume
que atingiu o máximo da largura de banda disponível ou que existe congestão da rede, e começa
então a enviar os dados a uma freqüência baixa novamente, aumentando-a depois gradualmente,
repetindo sempre este processo. O TCP fornece uma transmissão sem perdas, retransmitindo todos
os pacotes de dados que não cheguem ao seu destino. Com tudo isto, não consegue garantir que os
dados de mídia cheguem ao cliente a tempo de serem reproduzidos correctamente no tempo devido.
A outra solução de streaming, passa por usar um “Streaming Media Server”, que produz os
arquivos (podendo guardá-los localmente ou não) a serem transmitidos para o cliente. Uma página
Web que contém uma referência para o arquivo multimídia é guardada no Web Server, que pode ou
não estar colocado no mesmo computador que o Media Server.
Nesta solução, os dados são ativa e inteligentemente enviados para o cliente, significando que o
Media Server entrega o conteúdo a uma freqüência de acordo com a compressão a que os arquivos
63
áudio ou vídeo foram sujeitos. O servidor e o cliente estão por isso, em permanente contacto
durante o processo de transferência, para que o servidor possa responder a qualquer “feedback” do
cliente.
A transmissão de vídeo e áudio não guardado no servidor, isto é, produzido em tempo real, não
permite grandes atrasos na transferência, impondo condições rígidas nos atrasos e jitter dos pacotes
transmitidos (o jitter de um pacote é a diferença entre o intervalo entre dois quadros na produção e
dois quadros na reprodução).
Se a primeira solução de streaming não nos permite controlar os atrasos (a menos que existisse uma
espécie de serviços de primeira classe na Internet, pagos, mas com privilégios no que respeita a
prioridades em relação aos outros nos routers), com a segunda solução tal já se torna possível,
através de algumas decisões e truques. Por exemplo, podemos enviar o áudio e vídeo através de
UDP (User Datagram Protocol), protocolo que não garante a entrega dos pacotes, mas que não
retransmite a informação, resolvendo assim questão da baixa de freqüência no envio de dados a que
o TCP se vê obrigado quando entra no “Slow Start”. De seguida enumeram-se mais algumas
soluções, umas mais simples, outras mais complicadas, mas que melhoram muito o desempenho do
Streaming:
1. Variação do atraso na recepção dos pacotes (“jitter”). As técnicas usadas para minimizar
os efeitos do “jitter”, passam por numerar cada pacote com um número de seqüência, que
permite saber a ordem dos pacotes, marcá-lo com o instante de geração, que permite saber a
que ritmo devem ser reproduzidos e atrasar toda a reprodução de um tempo que permita
absorver as variações no atraso. (figura 16). Desta forma é menos provável que um pacote
chegue fora de tempo. Este atraso pode ser de tempo fixo ou de tempo variável (exemplo:
encurtando ou alongando os tempos de silêncio numa conversação) e devem ser escolhidos
conforme a aplicação e o atraso máximo que ela suporte [22];
64
Figura 16 - Atraso na reprodução (extraído de [21]).
2. Perda de Pacotes. Um outro problema que resulta de não usar um protocolo confiável é a
perda de pacotes, daí a introdução de mecanismos de prevenção e recuperação dessas
mesmas perdas. Como prevenção podemos ter um controle da taxa de transmissão e no
campo da recuperação encontramos mecanismos como o “Forward Error Correction” (FEC)
e o “Interleaving”;
2.1. “Forward Correction” (FEC). O FEC tem como base o envio de informação redundante
de forma a ser possível reaver informação perdida. O lado negativo desta abordagem é o
aumento do tráfego, e logo é necessário ter maior largura de banda disponível [22]. Existem
dois mecanismos de FEC mais conhecidos, o primeiro consiste em enviar por cada n pacotes
mais um pacote criado através do XOR dos n pacotes anteriores. Desta forma é possível
recuperar na íntegra um pacote perdido nesse grupo, porém se ocorrer a perda de mais de
um pacote a recuperação deixa de ser possível. Assim sendo o tamanho do grupo deve ser
relativamente pequeno, mas tendo atenção ao aumento de tráfego que daí se origina. O outro
mecanismo de FEC consiste em enviar em cada pacote uma cópia de baixa resolução
(qualidade) do pacote anterior. Desta forma quando se perde um pacote pode-se minimizar a
perda através da cópia que vem no próximo pacote. Este mecanismo falha quando ocorre a
perda de mais do que um pacote consecutivo.
65
2.2. “Interleaving”. O interleaving consiste em fragmentar um bloco de dados e distribuir os
fragmentos por vários pacotes. Um pacote vai conter fragmentos de vários blocos [22]
(figura 17). Desta forma quando se perde um pacote, ficamos com pequenas falhas nos
blocos de dados. Este mecanismo é muito usado em voz, porque em vez de ficarmos com
grande bloco de silêncio, ficamos com pequenas falhas no sinal de voz, sendo mais fácil ao
ser humano entender o conteúdo.
3. Controle da taxa de transmissão. O controle da taxa de transmissão tem como principal
objetivo reduzir a perda de pacotes devido a congestão na rede ou pouca largura de banda.
Este controle pode ser feito de várias formas, entre elas temos o “Stream Thining” e
“Multirate Switching” [23];
3.1. “Stream Thining”. Quando a rede se encontra momentaneamente congestionada, o
servidor descarta tramas de forma a minimizar a perda de pacotes. Existem políticas de
escolha das tramas a descartar, dependendo do tipo de dados que se envia, podendo haver
tramas de maior importância que outras para a qualidade dos dados reproduzidos [24];
3.2. “Multirate Switching”. Nesta abordagem quando existe um elevado número de pacotes
perdidos, o servidor baixa a qualidade dos dados (maior compressão) de forma dinâmica
para minimizar as perdas devidas a congestão, quando o servidor detecta que a congestão
diminui, torna a aumentar a qualidade dos dados multimídia. Do lado do cliente a congestão
torna-se um fenômeno transparente que, quando muito, é notado através de uma baixa
relativa da qualidade.
66
Figura 17 – Envio tipo “Interleaving” (extraído de [21]).
No próximo capítulo abordaremos os principais protocolos já existentes para a realização de
streaming de vídeo, de maneira a ilustrar a metodologia utilizada na confecção do software cliente-
servidor. No capítulo 7 descreveremos o protocolo MMTP, sem ainda apresentar o seu código, o
que deixaremos para o capítulo 8.
Deve-se aproveitar o momento para ressaltar as seguintes técnicas consideradas em nosso trabalho:
• uso da arquitetura cliente-servidor;
• utilização do protocolo UDP na camada de transporte, já que o TCP não apresenta boa
performance para aplicações em tempo real;
• utilização preliminar da plataforma Linux (incluindo sua interface gráfica);
• implementação em linguagem BSD-UNIX;
67
Capítulo 6
6. Protocolos de Transporte
Como já se disse anteriormente, o TCP apresenta atrasos devido a retransmissões e ao “Slow Start”
e não permite o multicast. As retransmissões deste tipo de tráfego são normalmente inúteis para o
video streaming, porque devido a restrições temporais, a aplicação de stream não pode aguardar
pela retransmissão de um pacote. Não existe interesse em garantir a entrega de um pacote, se essa
entrega não cumprir a meta temporal, que está relacionada com a reprodução da informação contida
no pacote.
O Streaming pode ser visto como um sistema em Tempo Real Rígido (“Firm Real Time”), visto que
não existe qualquer benefício no cumprimento atrasado do serviço.
É, portanto preferível aceitar a perda de pacotes e tentar recuperar desta perda através de outros
mecanismos. Por estas razões optou-se pelo uso do protocolo UDP ao nível da camada de
transporte, que não contém mecanismos de controle de congestão nem de retransmissão, o que se
traduz em menores atrasos.
Porém também o UDP apresenta diversos problemas, como a perda de pacotes ou a não garantia da
ordem dos pacotes entregues. Não resolvendo por completo os problemas dos atrasos e da variação
dos mesmos, apresenta, no entanto, características interessantes para este tipo de tráfego: permite
multicast e faz detecção de erros (através de um checksum) - os pacotes quando entregues não
contêm erros.
Para minimizar os problemas do UDP e porque é sempre preferível utilizar um protocolo standard
em vez de uma solução proprietária (que não permite interoperabilidade), criou-se um protocolo que
implementa alguns serviços sobre UDP, o Real Time Transport Protocol (RTP). Nos sub-capítulos
que se seguem descreve-se o RTP e outros protocolos de transporte muito importantes para o
streaming, como o RTCP e o RTSP [26].
68
6.1 Real Time Transport Protocol (RTP)
O RTP, pode ser visto como uma sub-camada de transporte, que normalmente assenta sobre UDP,
como mostrado na figura 18, embora tenha de ser integrado na camada de aplicação, através de
encapsulamento Este protocolo é usado para implementar funções de transporte para a entrega de
dados em tempo real. O protocolo encapsula pacotes de dados com um cabeçalho que contém a
informação necessária antes de os entregar à camada de transporte.
Figura 18 - Modelo Ozi de Camadas.
6.1.1 Estrutura do cabeçalho RTP
Neste sub-capítulo estuda-se a estrutura interna do cabeçalho RTP [27], em particular identificam-
se os diversos campos que contém assim como a sua função essencial. A estrutura é apresentada na
figura 19 e a descrição dos campos na figura 20:
69
Figura 19 - Estrutura do cabeçalho do RTP.
Version (V) - 2 bits – Versão do RTP. Atualmente 2.0;
Padding (P) - 1 bit – Indica se existem octetos de Padding no fim do pacote que não fazem
parte dos dados necessário para alguns algoritmos de encriptação que necessitam de blocos
de tamanho fixo;
Extension (X) - 1 bit – Indica que o cabeçalho apresenta campos extra;
CSRC Count (CC) - 4 bits – Indica o número de identificadores CSRC que seguem o
cabeçalho fixo, apresenta valor diferente de zero se os dados passaram por um mixer;
Marker (M) – 1 bit – Usado quando este pacote contém bits do frame anterior;
Payload (PT) – 7 bits – Indica o tipo de dados incluído no pacote;
Sequence Number – 16 bits – Aumenta de uma unidade por pacote, com valor inicial
aleatório. Serve para detectar perda de pacotes e permite ordenar pacotes à chegada;
Time Stamp – 32 bits – Reflete o instante em que foi criado o primeiro octecto de dados do
pacote, este tempo deve ser entregue por um relógio fiável e serve para efetuar a
sincronização e o cálculo do “Jitter” do lado do cliente;
Sincronization Source (SSRC) – 32 bits – Identifica a fonte que está a gerar os dados. O
número é aleatório de forma que duas fontes na mesma sessão RTP tenham valores
70
diferentes;
Contribution Source (CSRC) – 0..15 x 32 bits – Lista de identificadores de fonte que
contribuem para a sessão. O número é indicando pelo CC. Estes identificadores são inscritos
por mixers. Sendo um mixer um sistema intermédio que recebe pacotes RTP de várias fontes,
altera os dados e combina-os de forma a seguirem num só pacote. Exemplo: Numa
conferência de voz, não nos interessa receber pacotes de voz de todos os intervenientes, mas
sim um pacote com todas as vozes já misturadas.
Figura 20 – Explicação dos Campos do Cabeçalho do RTP.
6.2 RTP Control Protocol (RTCP)
O RTCP consiste num protocolo que acompanha o RTP e tem como objectivo monitorizar a sessão
RTP. Tanto as fontes, como os destinatários originam relatórios sobre o envio/recepção dos pacotes
RTP.
Estes relatórios contêm informações tais como o número de pacotes enviados, número de pacotes
perdidos, “jitter”, etc., úteis para que as aplicações possam efectuar operações tendo em conta uma
melhoria no serviço. Para que não haja excesso de tráfego RTCP, o ritmo de geração deste tipo de
relatório é alterado dinâmicamente, para que não ultrapasse 5% do tráfego total na sessão. Esta
situação de tráfego elevado poderia ocorrer facilmente devido ao multicast, porque temos muitos
clientes a enviar relatórios para o mesmo servidor.
71
6.2.1 Estrutura dos pacotes RTCP
O RTCP origina 2 tipos de relatórios, “Sender Type” (figura 21, com explicação dos campos na
figura 22) ou “Receiver Type” (figura 23), um participante só envia pacotes do tipo sender type se
for activo na sessão, ou seja se gerar pacotes RTP.
Tal como fizemos para o protocolo RTP, iremos analisar em mais detalhe a estrutura dos pacotes
RTCP [27].
6.2.1.1 RTCP - “Sender Type”
Figura 21 - Estrutura de um pacote RTCP Sender Type.
72
Version (V) – 2 bits – Igual ao RTP;
Padding (P) - 1 bit – Igual ao RTP;
Reception report count (RC) - 5 bits – Indica o numero de blocos de relatórios que contem;
Packet type (PT): - 8 bits – Indica o tipo de pacote enviado no caso de um SR, PT=200;
LENGTH – 16 bit – indica o tamanho total do SR;
Sincronization source (SSRC) – 32 bits – Igual ao RTP;
NTP Time stamp (NTP) – 64 bits – Instante em que o pacote é enviado. Útil para calcular o
RTT (Round Trip Time);
RTP Time stamp – 32 bits – Igual ao RTP;
Sender’s packet count – 32 bits – Número de pacotes enviados;
Sender’s Octect Count – 32 bits – Número de bytes enviados;
Fraction Lost – 8 bits – Fracção de pacotes RTP perdidos desde do envio do relatório
anterior;
Cumulative number of packets lost – 24 bits – Total de pacotes RTP desde do inicio da
sessão;
Extended highest sequence number received – 32 bits - 16 bits indicam o número de
sequência do último pacote recebido, outros 16 bits indicam o número de ciclos que os
números de sequência já sofreram;
Inter-arrival Jitter – 32 bits – Calculo do “jitter” médio;
Last SR timestamp – Timestamp do último relatório recebido;
Figura 22 – Explicação dos Campos do pacote RTCP Sender Type.
73
6.2.1.2 RTCP - “Receiver Type”
Este relatório é semelhante ao “Sender Type”, porém não contém os campos: NTP, RTP
Timestamp, Packet Count e Octect Count, pois este tipo de pacote é enviado pelos membros
passivos da sessão, que não enviam pacotes de dados, apenas de controle. O campo PT tem o valor
201.
Figura 23 - Estrutura de um pacote RTCP “Receiver Type”.
6.3 Real Time Streaming Protocol (RTSP)
O RTSP é um protocolo de nível de aplicação que possibilita o controle sobre a entrega de dados
com propriedades de tempo real. Atua como um “controle remoto de rede” para servidores
multimídia. Implementa comandos como PLAY, PAUSE ou RECORD e normalmente assenta
sobre TCP, embora também seja possível a sua implementação em UDP, para permitir multicast
[26].
74
6.3.1 Mensagens RTSP
O RTSP funciona com troca de mensagens textuais entre o cliente e servidor, seguindo o modelo
tipo “request/response” (pedido/resposta) como encontrado em outros protocolos como o HTTP. A
razão da utilização de um protocolo textual deve-se à simplicidade de interpretação para o ser
humano. Embora normalmente o protocolo seja transparente para a maioria dos usuários comuns, o
mesmo não se sucede para quem desenvolve aplicações que utilizem este mesmo protocolo.
• Mensagens de pedido (Request)
Como referido, mensagens RTSP são em tudo muito semelhantes ao HTTP. Apresentam
obrigatoriamente um método que identifica o tipo de pedido/comando que se pretende, o endereço
do objeto que se pretende aceder e a versão do protocolo. Opcionalmente pode apresentar uma lista
de parâmetros e ter um corpo que pode ser constituído por uma descrição da sessão em SDP
(Session Description Protocol) – o SDP é um formato de descrição de mídia que serve para
descrever sessões multimídia em termos de anunciação da sessão, convite para a sessão e outros
tipos de iniciações de sessões.
A syntax das mensagens-pedido RTSP é do tipo:
{MÉTODO} {URL} {VERSÃO DO PROTOCOLO} CRLF
{PARAMETRO} CRLF
...
{PARAMETRO} CRLF
CRLF
{CORPO OPCIONAL}
A título de exemplo apresenta-se a seguinte mensagem:
DESCRIBE http://mega.ist.utl.pt/xpto.rm RTSP/1.0
75
Cseq: 312
O parâmetro Cseq indica o número de sequência das mensagens e serve para que os intervenientes
possam identificar a que pedido corresponde uma determinada resposta [26].
• Mensagens de Resposta (Response)
As mensagens de resposta apresentam uma estrutura semelhante as mensagens de pedido. Tem uma
linha obrigatória que contém a versão do protocolo utilizado, um código numérico que identifica a
resposta e ainda uma descrição textual dessa mesma resposta. A mensagem pode também conter
uma lista de parâmetros opcionais, assim como um corpo.
Syntax das mensagens resposta RTSP :
{VERSÃO DO PROTOCOLO} {STATUS CODE} {DESCRIÇÃO TEXTUAL} CRLF
{PARAMETRO} CRLF
...
{PARAMETRO} CRLF
CRLF
{CORPO OPCIONAL}
Como exemplo apresentamos a resposta obtida em caso de o servidor conseguir realizar com
sucesso a acção pretendida:
RTSP/1.0 200 OK
Cseq: 312
76
• Métodos RTSP
Um dos métodos mais comuns disponíveis no protocolo é o setup. O setup é enviado pelo cliente
para o servidor com informações do tipo de transporte que aceita. Apresenta a seguinte estrutura:
SETUP {URL} {VERSÃO DO PROTOCOL} CRLF
{SEQUENCE NUMBER}
{Transport: } {opções}
De seguida pode analisar-se um exemplo do método setup:
SETUP rtsp://mega.ist.utl.pt/xpto.rm RTSP/1.0
CSeq: 3
Transport: rtp/avp;unicast;client_port=6970-6971;mode=play
Nesta transação, o cliente pede para receber os dados usando RTP por unicast no porto 6970 e 6971
(Porto RTP e Porto RTCP respectivamente).
Outros métodos muito comuns são o play, que pede ao servidor que inicie a transmissão dos dados,
o pause que pede ao servidor uma interrupção temporária na transmissão dos dados e teardown que
solicita ao servidor a finalização da sessão.
6.4 Seqüência Temporal de uma Sessão
Temporalmente uma sessão tem várias fases, representadas na figura 24. Quando um pedido é feito
através de HTTP, o servidor responde com um arquivo de descrição para então o browser invocar o
77
media player associado com aquele tipo de dados. A partir desse momento a interacção é feita entre
o media player e o servidor. O cliente (Media Player) envia ao servidor um pedido de SETUP a
indicar qual o conteúdo que pretende receber assim como qual o canal de transporte que deve ser
utilizado. Em seguida se o servidor puder satisfazer tal pedido envia uma resposta de confirmação
(200 OK). O cliente ao receber essa resposta e quando estiver pronto para receber os dados, envia
um pedido de PLAY, que o servidor mais uma vez confirma se tiver em condições para fazê-lo. A
ação que se segue é o início de uma sessão RTP e RTCP que controla o envio dos dados
multimídia. Neste exemplo o cliente solicita um PAUSE a dada altura, ao que o servidor responde
positivamente, e um solicita um TEARDOWN que finaliza a sessão RTSP [21].
Figura 24 - Esquema temporal de troca de mensagens (extraído de [22]).
6.5 Máquina de Estados do RTSP
Ao contrário do que acontece no HTTP, o RTSP tem estados associados, descritos por uma
máquina de estados simples como mostrado na figura 25.
78
Figura 25 - Máquina de Estados RTSP (extraído de [26]).
O estado inicial denomina-se de Init. Quando se processa o pedido/resposta de SETUP, o sistema
passa a um estado Ready, em que o cliente está pronto para começar a receber dados. Neste estado
pode ocorrer um pedido de TEARDOWN ou um pedido de PLAY. No primeiro caso passamos ao
estado inicial (estado init), e no segundo caso saltamos para um novo estado Playing, que se traduz
na recepção e reprodução dos dados multimídia por parte do cliente. Neste novo estado, pode
ocorrer ainda um pedido de PAUSE que leva o sistema de novo ao estado Ready [26].
6.6 Esquema de Ligações RTP/RTCP/RTSP
Como podemos facilmente concluir o RTP, RTCP e RTSP são protocolos complementares.
Tendo cada um a sua função, têm de coexistir na mesma máquina e a forma como tal é feito é
através da multiplexagem em diferentes portas, como se pode observar na figura 26. Nessa figura
são criadas três ligações, uma por cada protocolo. A ligação RTP usa uma porta par, o RTCP usa a
porta imediatamente seguinte e normalmente ambas as ligações utilizam o transporte UDP. O
RTSP usa normalmente a porta 554 do servidor e o transporte escolhido é o TCP.
Figura 26 - Esquema de ligações dos protocolos (extraído de [26]).
79
6.7 Resource Reservation Protocol (RSVP)
RSVP é um protocolo de controle que permite aos receptores requisitar uma determinada qualidade
de serviço para seu fluxo de dados. Aplicações de tempo real utilizam o RSVP para reservar a
quantidade necessária de recursos e roteadores ao longo do caminho de transmissão, a fim de obter
disponibilidade da largura de banda necessária para a transmissão.
A seguir, são descritos os elementos que compõem o esquema de funcionamento do RSVP:
a) Policy Control: trata das permissões da entidade que efetuou o pedido. Nomeadamente
administração, autenticidade, controle de acesso, pagamento de serviços, etc.;
b) Admission Control: verifica os recursos físicos da rede, decidindo se o pedido pode ou não ser
atendido;
c) RSVP Daemon: analisa os resultados dos blocos anteriores. Caso um deles falhe, envia uma
notificação de erro à entidade que efetuou o pedido. Caso contrário, estabelece os parâmetros dos
blocos packet classifier e packet scheduler de forma a atender ao pedido;
d) Packet scheduler: ordena os vários pacotes a serem transmitidos;
e) Packet classifier: atribui aos vários pacotes de informação diferentes categorias de QoS
correspondente.
[25] descreve as seguintes características para o RSVP:
a) fluxos RSVP são simplex: RSVP distingue remetentes de receptores. Mesmo que, um host possa
atuar tanto como remetente quanto como receptor, uma reserva RSVP somente aloca recursos para
streams em uma direção;
80
b) suporta unicast e multicast: desde que a reserva seja iniciada pelo receptor e seu estado seja leve,
RSVP pode facilmente manipular mudanças em membros e rotas. Um host pode enviar mensagens
IGMP (Internet Group Management Protocol) para inscrever-se em um grupo multicast; c) o RSVP
é orientado ao receptor e manipula receptores heterogêneos: em grupos heterogêneos de multicast,
receptores têm diferentes capacidades e níveis de QoS. Os remetentes podem dividir o tráfego em
muitos fluxos, cada um é um fluxo RSVP com diferente nível de QoS.
d) compatibilidade: esforços têm sido feitos para executar o RSVP tanto sobre o IPv4 (protocolo IP
versão 4, atualmente em uso) quanto sobre o IPv6 (futura versão desenvolvida para o protocolo IP).
6.8 Pilha de Protocolos
Para tornar mais claro como estes protocolos são empilhados, apresentamos o seguinte esquema
(figura 27) que representa as três camadas superiores do modelo OSI.
Figura 27 - Pilha de Protocolos (extraído de [22]).
6.9 Players de Streaming e suas Tecnologias
Para visualizar os vídeos que são descarregados da Internet por “download” completo, basta ao
utilizador possuir um programa, denominado player, que consiga abrir e mostrar o conteúdo de
81
arquivos do tipo daquele que o utilizador descarregou. Vários programas podem abrir o mesmo tipo
de arquivos, desde que esse tipo não seja proprietário, e por isso se usam esses formatos na
distribuição de arquivos por “download”.
Já no método de streaming, os formatos usados são proprietários, o que leva à necessidade de
programas especiais para o conseguirmos visualizar. Esses programas são denominados “Streaming
Players” e serão referidos apenas como players daqui para a frente, por uma questão de
comodidade.
Conseguem-se então destacar três grandes players de uso mundial, que funcionam cada um com o
seu formato de streaming. Convém realçar que cada um destes players não serve apenas para
trabalhar com streaming, pois na generalidade, todos eles abrem os formatos não proprietários de
áudio e vídeo (como MPEG-4, MP3, etc.). Esses players são o Windows Media Player, o RealOne
Player e o QuickTime Player e os seus formatos streaming suportados são o Windows Media, o
Real Media e o Apple QuickTime, respectivamente [23]. Apesar de cada combinação
(formato/servidor/player) destas três soluções serem completamente funcionais e suficientes para
realizarmos uma sessão servidor/cliente de streaming, existe uma grande lacuna de compatibilidade
entre si, pelo fato de serem soluções proprietárias. Em primeiro lugar, cada uma usa um codec de
mídia diferente, resultante em formatos de arquivo diferentes, (um codec é um formato de
compressão dos dados, neste caso, dados vídeo), e em segundo usam diferentes tipos de controle
e/ou protocolos de transporte. De seguida passa-se à explicação mais detalhada de cada uma destas
soluções.
6.9.1 Apple QuickTime
Este é o formato mais usado pelas companhias produtoras de filmes para distribuírem trailers dos
seus filmes, apesar de ser menos popular que os outros dois formatos, pois pertence à Apple. As
primeiras versões do player da Apple, o QuickTime Player, não suportavam streaming, apenas o
“download” progressivo. Mas as última versões são baseadas no QuickTime Streaming Server, que
usa RTSP para entregar correctamente os conteúdos. Este servidor foi desenhado para o Sistema
Operativo Mac, mas como esta disponível como “open source” numa versão chamada “Darwin
82
Streaming Server”, funciona para Linux, Solaris e Windows. Uma vantagem do QuickTime é a sua
compatibiliadade com a maioria dos “Web Browsers”, através de plug-in’s, outra é a de que se o
streaming for feito com HTTP (uma das opções), então pode ser guardado no cliente.
Para se visualizar um streaming produzido por esta tecnologia basta pois introduzir um url de um
arquivo (neste caso proprietário) com extensão “.mov” num browser (se este tiver o plug-in
instalado) ou então no QuickTime Player. Se a inicialização do processo for feita no browser, este
devolve o controle ao QuickTime, que começa por estabelecer a sessão com o protocolo RTSP à
qual o servidor responde com RTSP e SDP identificando os atributos do dono do mídia (figura 28):
Owner Username: Bloomberg
Session ID: L.P.
Session version: 3137919098
Owner Network Type: 3138533880
Owner Address Type: IN
Owner Address: IP4 172.20.45.123
Session Name: Bloomberg TV Spanish 56
Figura 28 – Exemplo mensagem SDP de um servidor (extraído de [22]).
Para além da identificação do dono e seus atributos, o descritor de sessão também contém 2
descritores mídia, um para o áudio e outro para o vídeo, cada um seguido de varias linhas com
atributos, como se observa na imagem exemplo da figura 29:
media= audio 0 RTP/AVP 12
attribute= control: trackID=1
83
media=video 0 RTP/AVP 100
attribute=rtpmap:100 X-SorensonVideo
attribute=cliprect:0,0,1,20,160
attribute=bufferdelay:8
attribute=control:trackID=2
Figura 29 – Exemplo de atributos da mensagem SDP (extraído de [22]).
Os pacotes com informação são distribuídos usando o protocolo RTP. Durante a sessão, ambos
cliente (aplicação QuickTime) e servidor determinam estatísticas como largura de banda
disponíveis, pacotes perdidos e enviados, jitter, etc. e enviam-nas mutuamente através do protocolo
RTCP. Para terminar a sessão é usado novamente RTSP (figura 30).
Figura 30 – Exemplo do esquema de mensagens da Apple (extraído de [22]).
84
As mensagens RTSP são enviadas usando o Protocolo TCP e as mensagens RTP e RTCP são
enviadas através de UDP. Se a aplicação do receptor estiver protegida com uma firewall (que
normalmente não recebe pacotes UDP), então todas as mensagens serão enviadas com TCP [28].
6.9.2 Real Media
Este é formato de streaming proprietário da RealNetworks, em que a principal diferença desta
tecnologia para a da Apple QuickTime é que em alternativa aos protoclos RTP/RTCP, o Real
Media usa mais um protocolo proprietário chamado Real Data Transport Protocol (RDT), do qual
existe ainda muito pouca informação. A RealNetworks está a adoptar progressivamente o RTP e o
RTCP, sendo as últimas versões já compatíveis com esses protocolos. No entanto, estão a ser
adicionadas extensões proprietárias por parte da Real, o que vai fazer com que a compatibilidade já
não seja total.
Para se visualizar este tipo de streaming, procede-se da mesma forma que se procede para o
QuickTime: introduzindo um url num browser ou no Real One Player, mas desta vez o arquivo
pretendido tem extensão .rm. Tal como no QuickTime, existe também um controle que é feito
usando mensagens RTSP (por TCP) e RDT (por UDP) (figura 31).
85
Figura 31 – Exemplo do esquema de mensagens da Real (extraído de [22]).
Link para o streaming do canal bloomberg:
rtsp://media5.bloomberg.com:554/farm/*/encoder/btv_us.rm
No caso de o cliente possuir uma firewall que lhe impeça de receber pacotes UDP, então todas as
mensagens serão enviadas usando apenas o TCP.
Para combater as flutuações da largura de banda da rede e poder assim apresentar um serviço sem
perdas, o Real Media apresenta um mecanismo chamado “SureStream”, descrito no sub-capitulo
seguinte [29].
86
SureStream
Este mecanismo traduz-se num escalonamento dinâmico do “bit rate” a que são enviados os dados.
Com este escalonamento, a Real consegue trazer qualidade e confiabilidade ao streaming,
beneficiando o utilizador ao fornecer-lhe um vídeo sem interrupções, independentemente das
variações da rede. Tal é possível porque o conteúdo a ser enviado pelo servidor é primeiramente
guardado num arquivo de múltiplos “data rates”, sendo depois escolhido o “data rate” adequado ao
cliente e à sua ligação. Este rate vai variando ao longo da sessão, à medida que o cliente vai
possuindo mais ou menos largura de banda.
Durante a sessão, o cliente monitora a largura de banda disponível e as características de perdas da
conexão e instrui o servidor para mudar para o stream com o “bite rate” mais adequado para tais
características. Com isto, quando o servidor se depara com uma situação de congestão da rede, em
vez de se perderem pacotes ou o vídeo parar no lado do cliente, o servidor automaticamente começa
a transmitir a um “bit rate” mais baixo, evitanto essas percas de pacotes, o que resulta numa
manutenção da qualidade da recepção (figura 32).
A grande contrapartida deste método, é o de que o arquivo SureStream aumenta dramaticamente,
uma vez que possui várias “data rates” do mesmo vídeo no interior, sendo por isso aconselhável a
escolha de um limite máximo do número de rates a codificar
A produção dos filmes SureStream é feita pela aplicação RealNetworks Producer.
6.9.3 Windows Media
O Windows Media é o formato streaming proprietário da Microsoft, desenhado para ser embebido e
controlado por outras fontes como páginas HTML (Hypertext Markup Language) ou comandos
Java/VBScript. A principal vantagem deste tipo de streaming revela-se na habilidade de controlar e
ligar todas as fontes Web de mídia compatíveis, na medida em que basta um browser suportar
87
módulos plug-in para a funcionalidade streaming ficar disponível. A contrapartida é que sendo um
produto Microsoft, a sua compatibilidade só é total com outros produtos/aplicações Microsoft.
A solução de streaming oferecida pela Microsoft é completamente diferente das oferecidas pelos
outros dois concorrentes. Além do protocolo HTML standard é usado um conjunto completo de
protocolos proprietários da Microsoft. O mais importante dos protocolos é o Mutimedia Server
Protocol (MMS), que contém o mecanismo de entrega de dados, para garantir que os pacotes
chegam ao cliente, e o mecanismo para lidar com os pedidos do clinte (por exemplo STOP, PLAY,
PAUSE, etc.). Os servidores que usam MMS possuem url do tipo “mms://” ou “mmst://” para sites
que usam apenas TCP e “mmsu://” para sites UDP. Se não for especificado, o servidor
automaticamente escolhe qual o melhor protocolo de transporte a usar na ligação.
Outro protocolo proprietário é o Media Stream Broadcast Distribution (MSBD) que se utiliza para
transferir dados stream do Windows Media Encoder para o Windows Media Server, este último a
aplicação responsável pela entrega do streaming ao cliente, enquanto que o primeiro fica com a
tarefa de codificar o streaming num formato de arquivo (proprietário) “.asf”.
O Windows Media automaticamente detecta as congestões na rede e ajusta as propriedades do vídeo
streaming a entregar, de modo a maximizar a qualidade. Isto é feito pelo chamado “Intelligent
Streaming” [30], descrito no sub-capítulo que se segue.
Para terminar, convém referir que se se pussuir um plug-in integrado num browser, para se
visualizar este streaming basta fazer como nos outros dois anteriores, digitando o url (exmplo:
“mms://media2.bloomberg.com/btv_uknb.asf”). Outra opção é digitar o url diretamente na
aplicação Windows Media Player.
Link para o streaming do canal bloomberg: mms://media2.bloomberg.com/btv_uknb.asf
Intelligent Streaming
À semelhança do SureStream da RealNetworks, também o Intelligent Streaming da Microsoft atua a
nível do “bit rate” de codificação do vídeo a enviar para o cliente, detectado automaticamente as
congestões da rede e ajustando a codificação para evitar que a qualidade do streaming baixe. Como
a Tecnologia Windows Media se baseia sobre um sistema ponto-a-ponto (TCP), o cliente e o
88
servidor comunicam entre si para trocarem informação sobre as características da rede, importantes
para a atuação do Intelligent Streaming.
Para garantir uma apresentação contínua de vídeo, este método realiza duas principais ações: envia
sempre o stream de dados com um “bit rate” adequado à largura de banda disponível e ajusta-o
dinamicamente sempre que essa largura de banda se altera.
O descrito acima é possível porque a partir de uma fonte, são codificadas até um máximo de 10
video streams com ”bit rates” diferentes, todos no mesmo arquivo. Quando o Windows Media
Player está conectado ao Windows Media Server, apenas um vídeo stream é recebido: aquele que
for mais apropriado para a largura de banda disponível, e convém referir que este processo é
totalmente invisível para o utilizador.
As estratégias de controle aplicadas são as seguintes:
· no início, o servidor e o cliente determinam automaticamente a largura de banda
disponível, e então o servidor selecciona e serve o vídeo stream com o bit rate
apropriado;
· durante a transmissão, se a largura de banda decrescer, o servidor detecta-a
automaticamente e muda para um stream de banda mais baixa. Se a banda aumentar
de novo, o servidor muda para um stream de banda maior, mas nunca superior ao
stream da largura de banda original;
· se a largura de banda for muito baixa para suportar streaming, o cliente e o
servidor degradam a qualidade da imagem inteligentemente.
A arquitetura de Alto Nível do “SureStream” e do “Intelligent Streaming” encontram-se ilustradas
na figura seguinte:
89
Figura 32 – Arquitetura de Alto Nível da Troca de Multi-rate (extraído de [22]).
90
Capítulo 7
7. MMTP – Multimedia Multiplexing Transport
Protocol
Segundo [3] e [31], devido à natureza periódica que apresentam os tráfegos multimídia, acredita-se,
geralmente, que os protocolos mais apropriados para tais aplicações sejam os que são sensíveis às
variações ao longo do tempo (“rate-based”). Para tanto, tais protocolos devem utilizar de
mecanismos como estimação de largura de banda disponível e variância do congestionamento dos
pacotes presentes na rede. Tal abordagem torna-se mais crítica quando nos referimos às
comunicações “wireless”, mais susceptíveis às variações de banda. Um exemplo de um protocolo
sensível às variações de taxa é o NETBLT [33], contudo, este foi projetado para o transporte de
dados, o que na maioria dos casos, os torna inviáveis para aplicações de fluxos multimídia.
O MMTP é um protocolo de transporte que apresenta mecanismos mais apropriados por trabalhar
com relações heterogêneas. Separando o protocolo de transporte do protocolo de rede, torna-se
possível realizar, em uma mesma conexão cliente – servidor, transições entre diferentes interfaces
de rede. No MMTP, tal processo é bastante natural e não é necessário nenhum processo de
comutação nas “camadas” abaixo da camada de aplicação. Ou seja, maior aproveitamento dos
recursos disponíveis. Além disso, a ativação de uma nova interface de conexão não inviabiliza as
outras, pelo contrário, elas continuam sendo monitoradas para sua possível re-utilização. Cada nova
interface que se torna disponível é adicionada ao conjunto das interfaces previamente instaladas.
Como nos outros protocolos de transporte, o MMTP provê a adaptação da banda exigida pelo fluxo
multimídia à banda disponível no canal. Isto é feito através da interação entre o protocolo de
transporte e o código da aplicação.
O MMTP pode ser visto como dois protocolos de sentido único, um da fonte para o receptor,
carregando dados, e outro do receptor para a fonte, carregando informação de controle. No tocante
do tráfego multimídia, o MMTP tem a vantagem adicional de geralmente não necessitar das
“despesas” de banda, associadas ao funcionamento do TCP.
91
O MMTP suporta a transmissão dos fluxos de dados sensíveis no tempo que podem ser gerados em
tempo real ou através de dados armazenados. Dado as características dos fluxos de dados em
termos das exigências de taxa e de largura de banda exigida pelo quadro, o MMTP usa todos os
canais de comunicação disponíveis para a transmissão dos dados. Como os recursos disponíveis dos
canais mudam, o MMTP adapta-se, adicionando ou removendo os canais como necessário. O
MMTP fornece um serviço do tipo melhor esforço, ou seja, se os canais disponíveis não fornecerem
largura de banda suficiente para o fluxo da aplicação, o MMTP estima os pacotes que não poderão
chegar no tempo correto (fora do prazo) e os descarta, informando para a aplicação a falta dos
recursos necessários.
MMTP é um protocolo que multiplexa os pacotes dos dados através dos múltiplos canais de
comunicação. A tarefa principal que cabe ao MMTP é a decisão a respeito de qual canal usar para
transmitir o pacote atual. Esta decisão é baseada em estimações da largura de banda e características
de atraso de cada um. Após o processo inicial, dois mecanismos do controle são usados para adaptar
a taxa de transmissão à largura de banda do canal: mensagens de diminuição da taxa e sondagem do
canal. Nesta seção, nós apresentaremos os parâmetros do protocolo e descreveremos sua operação.
7.1 Estrutura da comunicação A estrutura do MMTP foi projetada no contexto de estruturas que fornecessem recursos para o uso
simultâneo de múltiplas tecnologias de comunicação da camada de enlace. Sua estrutura fornece as
seguintes funcionalidades: Primeiramente, monitores para a verificação de disponibilidade dos
canais de comunicação para cada conexão. Técnicas de sondagem dinâmicas são usadas para
encontrar canais novos e manter a informação sobre os canais já em utilização. Segundo, a estrutura
vasculha os canais disponíveis para obter informações sobre determinados parâmetros, tais como a
largura de banda disponível e o atraso de propagação. A informação sobre os canais ativos é
coletada através dos protocolos que os estão utilizando. A estrutura mantém o monitoramento
dinamicamente, fornecendo informações sobre as conexões disponíveis e sobre as que estão em
atividade. Esta estrutura de comunicação está sendo projetada conjuntamente com os protocolos que
a estarão utilizando, como o MMTP. Os detalhes da estrutura estão além do escopo deste trabalho.
92
7.2 Características dos Dados Os fluxos de dados multimídia podem ser gerados em tempo real, na taxa em que necessitam ser
transmitidos. Freqüentemente, tais aplicações têm tolerância muito pequena para atrasos. Os
quadros dos fluxos de dados multimídia têm a característica de excederem o tamanho máximo da
transmissão e devem ser fragmentados em múltiplos pacotes. A fragmentação inteligente pode ser
feita de maneira a permitir que a recepção processe partes do quadro, mesmo que o quadro inteiro
não tenha chegado. Mais informações sobre o processo de fragmentação e posterior montagem de
quadros multimídia podem ser adquiridos em [34].
7.3 Comportamento inicial Quanto ao comportamento inicial, a aplicação define a taxa necessária para o quadro. O protocolo
“pergunta” à estrutura de comunicação para obter o número de canais disponíveis e uma estimativa
do atraso de propagação e da taxa do pacote para cada canal. Para ver se a taxa requerida pelo
quadro pode ser utilizada, o protocolo calcula a taxa do canal agregado disponível. Há dois casos:
1.taxa do quadro > taxa do pacote
Através de informações obtidas do pacote, a aplicação é notificada quais deles deverão ser
descartados. A aplicação pode decidir se aborta a transmissão ou se muda a taxa dos quadros para
continuar.
2.taxa do quadro < taxa do pacote
A estimação indica que há bastante largura de banda para a transmissão. O atraso inicial é um
parâmetro da exibição do fluxo, que diz à aplicação da recepção quanto tempo esperar antes de
jogar o primeiro quadro. O atraso inicial pode ser escolhido entre o inicial com máximo de atraso
para a aplicação e o inicial com mínimo de atraso, calculado pelo protocolo através do atraso de
propagação dos canais ativos. Quanto maior for o atraso inicial, maior será a folga que o protocolo
tem para compensar para o jitter, através da inserção de instantes de tempo ao fim do prazo de cada
quadro. A aplicação de recepção protegerá um número de quadros proporcional à relação entre o
atraso inicial e o período do quadro (o inverso do atraso de quadro) antes de iniciar a exibição.
93
O atraso inicial é sempre maior ou igual ao mais longo atraso de propagação para os canais que
estão sendo usados e não é dependente de qual canal esta sendo usado para transmitir o primeiro
pacote. Os exemplos em figura 33 descrevem o comportamento inicial que supõe dois canais e um
pacote por quadro. A figura 33a mostra o atraso inicial, quando o primeiro pacote é transmitido no
canal com maior atraso de propagação, e a 33b mostra o atraso inicial quando o primeiro pacote é
transmitido no outro canal. Em ambos os exemplos, o emissor recebe o quadro 0 no tempo t e
quadro 1 no tempo t + 1/ taxa do quadro. Na figura 33a, o primeiro quadro foi transmitido no canal
com o maior atraso de propagação, assim a exibição pode começar logo que o quadro 0 for
recebido, desta forma, o quadro 1 terá chegado no fim do período de exibição do quadro 0. Se o
atraso de propagação nos dois canais for muito diferente, é possível que o quadro 1 chegue antes do
quadro 0. Nesta situação, armazenamos o quadro 1 e ainda assim que o quadro 0 é recebido,
começamos a exibição. Na Figura 33b, o quadro 0 chega primeiro, mas a exibição deve ser atrasada
até que nós estejamos dentro do período para o recebimento do quadro 1, caso contrário, pode haver
uma falha ao final da exibição do quadro 0. Pelo fato do MMTP usar a estimação da largura de
banda disponível e o atraso de propagação, é difícil executar a opção 2, pelo fato do atraso inicial
depender diretamente do valor estimado para o atraso de propagação em ambos os canais.
Transmitir o primeiro pacote no canal com maior atraso de propagação permite que a exibição seja
auto-sincronizável.
94
Figura 33: Comportamento incial para o MMTP com dois canais
95
7.4 Controle de fluxo O controle de fluxo para MMTP pode ser modelado como um conjunto de protocolos de controle de
taxa, um para cada canal, todos prestando manutenção para uma fila única. São geradas “fichas”4
para cada canal baseado em estimativas da largura de banda disponível que são etiquetadas com as
estimativas do atraso de propagação. Os pacotes são introduzidos na fila na taxa de quadro da fonte
e necessitam ser transmitidos em um dos canais disponíveis. Este tipo de problema de gerência de
recursos é utilizado eficientemente para modelagem de filas de processos em sistemas operacionais
com multiprocessadores de tempo real [35], onde o tempo de processamento é obtido de acordo
com o tempo de transmissão para cada canal. Os pacotes são transmitidos em um canal se houver
uma ficha e se o atraso de propagação for pequeno o suficiente para assegurar que o quadro chegará
a tempo. Fichas são usadas para cada transmissão em um canal e fichas novas não são geradas até
que a ficha velha seja usada. Quando um quadro chegar, há três possibilidades:
1. Nenhuma ficha está disponível: o quadro tem que esperar até que uma ficha seja gerada em um
canal que o possa entregar em tempo. Se nenhuma ficha for gerada antes do fim do prazo do
quadro, ele é rejeitado.
2. Exatamente uma ficha está disponível: se o canal correspondente puder entregar o quadro a
tempo, o quadro é emitido. Do contrário, voltamos ao primeiro caso.
3. Múltiplas fichas disponíveis: se mais de um canal puder entregar o quadro, o canal com maior
atraso de propagação é escolhido. Manter o canal com o maior atraso de propagação cheio ajuda a
criação de um trajeto mais rápido de resposta. Se nenhum canal puder satisfazer o prazo do quadro,
o quadro tem que esperar, como no caso 1.
Mesmo se nenhum dos canais estiver disponível para transmitir um quadro, os quadros enfileirados
podem ainda ser transmitidos se um novo canal com menor atraso de propagação for adicionado, ou
ocorrer uma grande diminuição no atraso de propagação previsto para um dos canais atuais,
permitindo a transmissão bem sucedida do pacote.
4 “fichas” do inglês tokens, termo comumente utilizado nas arquiteturas de redes.
96
7.5 Controle de Congestionamento No MMTP, o controle de congestionamento é implementado como uma técnica reativa, baseada na
estimação da largura de banda. Ambos, o atraso de propagação e a largura de banda disponível em
um canal, variarão devido às mudanças de roteamento e às interferências causadas por outros
tráfegos. A largura de banda disponível é igual à diferença entre a largura de banda máxima e a de
utilização efetiva para cada conexão. O atraso de propagação é composto por duas partes: o atraso
real de propagação dos bits nas linhas da transmissão e o tempo gasto durante o processamento em
cada roteador no trajeto. A primeira parte é reparada na ausência de mudanças de rota, mas o
segundo crescerá de acordo com o tamanho das filas nos roteadores.
Para evitar o congestionamento, o protocolo tenta manter a largura de banda demandada abaixo da
largura de banda disponível em um canal. Isto é feito medindo a largura de banda disponível e
mudando as taxas nas quais os pacotes são emitidos para um valor compatível. A largura de banda
disponível é inferida medindo-se os intervalos entre as entregas dos pacotes no receptor. As
medidas dos instantes de chegadas dos pacotes são reenviadas para o transmissor, atualizando suas
estimativas. Pelo fato dos pacotes serem inseridos em intervalos regulares em cada canal, o tempo
entre as recepções deve convergir para os períodos utilizados pelos quadros desse canal, se houver
largura de banda suficiente. Se os tempos entre as chegadas começarem a crescer, isto significa que
em algum lugar do trajeto um roteador está trabalhando acima da capacidade, gerando filas.
7.5.1 Estimação dos parâmetros
Para estimar os parâmetros básicos, a largura de banda e o atraso de propagação, o tempo entre as
chegadas dos pacotes é monitorado no receptor para cada canal. O tempo entre chegadas é
comparado ao período dos quadros estão sendo transmitidos nesse canal (presente em cada
cabeçalho do pacote). Com um atraso estável de fileiras, o tempo entre as chegadas deve convergir
a este período, como dito anteiormente. Como os atrasos de filas mudam, o jitter é introduzido e o
tempo entre as chegadas varia. Um total para o jitter deve ser zero se não houver nenhuma mudança
em características do canal, e com isso estabilizando o tempo médio entre as chegadas. Um pacote
que chegue atrasado faz aparentemente que o próximo pacote chegou mais cedo, assim a soma dos
jitters deve cancelar. O jitter acumulado é uma média dinâmica dos últimos pacotes de n, onde n é
um parâmetro de implementação. O valor de n deve ser tal para que tenha a mesma granularidade
97
temporal das mensagens “keep-alive”5, assim estas podem carregar dados significativos de volta
para o emissor.
Há dois casos especiais quando o jitter total não é zero:
• Quando houver um congestionamento, os tamanhos da fila nos roteadores crescem, e isto é
visto no receptor como um aumento positivo no jitter acumulado. Neste caso, o receptor
transmite para trás uma mensagem que pede uma diminuição da taxa de transmissão,
evitando assim o congestionamento. Este é realmente um mecanismo melhor do que
diminuir a largura de banda usada através de pacotes descartados. Usar pacotes descartados
como uma medida de conter o congestionamento é uma técnica reativa e deve ser usado
somente quando o congestionamento já está presente. Usando o jitter acumulado para
sinalizar congestionamentos em potencial, o protocolo pode tentar impedir que os pacotes
sejam descartados. Além disso, os pacotes descartados não são uma boa medida do
congestionamento para “hosts” móveis, pelo fato das ligações wireless terem perdas muito
mais elevadas do que transmissões por meios físicos normais.
• Quando o atraso de propagação pára, haverá uma parada no tempo entre as chegadas de um
“time-slot”. Após isso, a taxa presente convergirá outra vez à taxa de transmissão. Para
detectar se esta interrupção não é causada por um pacote precedente que estivesse muito
atrasado, o histórico do jitter é analisado. Se o teste padrão mostrar um alto valor positivo
seguido por alto valor negativo (o que faz com que o jitter se cancele), este evento é então
ignorado. Se a tendência for estável, e o pacote adiantado é efetivamente de dados, então a
próxima mensagem keep-alive irá carregar uma indicação que poderá haver largura de
banda extra, disponível nesse canal.
A mensuração de períodos entre chegadas funciona bem para impedir o congestionamento, mas não
é eficaz para medir a largura de banda adicional ou de banda inativa em um canal. O problema é
que em cada taxa de transmissão, a largura de banda máxima medida pela aplicação é igual à
largura de banda que está disponível para emissor. Conseqüentemente, nós podemos diminuir a taxa
de transmissão, contudo não é possível aumentar-la com este método. Um outro mecanismo é
necessário para medir a largura de banda disponível além do que já está sendo usado.
5 A expressão keep-alive, comumente utilizada nas especificações (RFC) referente ao http, se refere a conexões TCP que se persistem a inúmeros novos pedidos. Versões mais anteriores do http não implementavam conexões keep-alive, ocasionando em um constante fluxo de pedidos de conexões TCP a cada envio de requisição. Mais informações sobre protocolos de aplicação podem ser encontradas em [32].
98
7.5.2 Sondagem
O mecanismo que o MMTP usa para medir um aumento na largura de banda disponível é a
sondagem (probing). Há duas maneiras fáceis de executar a sondagem. A primeira é o aumento
aditivo: consiste em aumentar continuamente a taxa da transmissão em quantidades pequenas na
ausência da diminuição de pedidos, mantendo estáveis as medidas dos tempos entre as chegadas. Se
esses intervalos começarem a crescer, isso significa que foram enviados pacotes demais ou que a
transmissão está experimentando um congestionamento, assim, o protocolo tem que diminuir a taxa.
O problema com esta técnica é que os ganhos virtuais de largura de banda não são testados até que
haja a necessidade, pelo fato da taxa dos pacotes ser limitada pela taxa dos quadros. Além disso,
quando a largura de banda virtual, medida pelos aumentos da taxa, for necessitada, elas podem não
estar disponíveis. A segunda maneira usa pacotes de sondagem. Um pacote de sondagem é
transmitido para trás juntamente com um pacote normal. O tempo entre as chegadas do pacote
normal e do pacote de sondagem deve ser zero. Entretanto, normalmente este valor não será zero,
mas pelo menos servirá para medir os atrasos das filas introduzidas pelos roteadores.
Os pacotes de sondagem devem carregar o “payload”6 útil, pois serão provenientes de um pacote
normal. O problema é que pode não haver dados suficientes disponíveis para transmitir dois pacotes
para trás. Neste caso, um pacote vazio pode ser usado. Este tipo de sondagem pode ser prejudicial
se o sistema estiver trabalhando no limite: a largura de banda perdida no pacote de sondagem pode
fazer com que um pacote útil seja descartado.
7.6 Adicionando e removendo canais A lista inicial dos canais disponíveis proveniente da estrutura de comunicação é recebida quando o
protocolo é iniciado. Com o passar do tempo, canais novos podem se tornar disponíveis e canais
velhos podem ser perdidos. A estrutura notifica ao MMTP tais eventos e ainda fornece como
informação subordinada, a estimativa da largura de banda disponível.
6 Payload deve ser entendido como a parcela de um pacote não contendo dados propriamente dito, mas sim informações relacionadas ao funcionamento do sistema, tais como endereçamento e rotas utilizadas.
99
Quando um canal novo for adicionado ao processamento do protocolo, a largura de banda
disponível tem que ser medida se estes dados não estiverem atualizados. Para fazer a sondagem
inicial, o protocolo usa o método do pacote par [36], que é o mesmo mecanismo de sondagem
utilizado pelo MMTP: duas mensagens são transmitidas no sentido oposto para o fim da fila e o
tempo entre as suas chegadas é medido no receptor. Isto é usado como estimação da largura de
banda máxima nessa ligação e serve para atualizar os parâmetros do emissor. Quando um canal for
perdido, uma mensagem de fim de registro é emitida ao ponto de conexão que usa o canal com
menor atraso. Isto remove essa interface do processamento do protocolo. A mensagem contém
também o último pacote recebido nesse canal. Os pacotes proeminentes são colocados sobre a fila
para a retransmissão, com os mesmos confinamentos dos outros pacotes (estes também não serão
transmitidos se não puderem chegar até o fim do prazo.)
Cada canal ativo emite mensagens keep-alive periodicamente. Além de notificar ao seu respectivo
ponto de conexão que o canal está ainda aberto. Estas mensagens carregam atualizações das
medidas executadas no receptor, os tempos entre as chegadas das mensagens, a largura de faixa
disponível estimada e o número dos pacotes atrasados e perdidos. Se um keep-alive não for
recebido, o emissor envia uma mensagem de pergunta para assegurar se o canal está ainda aberto ou
se uma mensagem de controle foi perdida.
Um canal pode estar presente no processamento, mas não carregar nenhum dado se o atraso nele for
maior do que nos a folga (caso exista). Isto pode acontecer se a transmissão começar antes que o
canal seja adicionado ao processamento. Se o atraso na nova linha for maior do que D0 (atraso
inicial), o canal pode nunca ser usado para carregar dados para essa transmissão. Ele pode ainda
carregar mensagens de controle, mas será usado somente se nenhum outro canal estiver disponível.
As mensagens de keep-alive normais e de sondagem são feitas no canal, no caso em que o atraso cai
para um nível utilizável. Um canal pode também ser trocado se o atraso aumentar e a largura de
banda cair a níveis muito baixos. Isto pode acontecer, por exemplo, enquanto o usuário se move
para fora da área de cobertura e as condições da camada de enlace se deteriorem, ou pelo
congestionarem. Enquanto nenhuma mensagem de fim de registro chegar, pacotes keep-alive e de
sondagem continuarão. Se somente um canal estiver disponível e as mensagens keep-alive não
estiverem sendo recebidas, o protocolo sinalizará que a ligação pode ser quebrada.
100
7.7 Comparação entre MMTP e UDP A instalação de teste para o MMTP teve um processo fonte que criou quadros na periodicidade dada
e os enviou para o proxy7. O proxy transmitiu estes quadros para o receptor móvel. O processo do
cliente não gravou a mesma informação de quadros perdidos. Mudar o tempo de interrupção
mudaria o número de quadros transmitidos porque o protocolo poderia supor que mais quadros
poderiam não chegar no do prazo.
A versão atual do MMTP está ainda no estágio de desenvolvimento, assim o desempenho está
abaixo do máximo teórico. É demasiado conservador em pequenas distâncias, no tocante de redes
sem fio, pois descarta muitos pacotes e parece ter pior performance do que outros protocolos em
determinados períodos. Entretanto, ao comparar o desempenho do MMTP com o do UDP, deve-se
indicar que recursos estão sendo desperdiçados em ambas redes com e sem fio. As conexões de alta
velocidade mascaram este efeito, permitindo que o fluxo percorra através da rede até que os pacotes
sejam descartados nas estações base sem fio. Isto não aconteceria na Internet. O MMTP descarta
os pacotes na fonte, assim somente os pacotes que tendem a chegar no tempo são realmente
transmitidos. A figura 33 mostra o número de quadros desperdiçados. Tais quadros foram
recebidos depois que seu prazo tinha expirado.
7 Proxy; elemento de rede que atua ao nível de aplicação. Basicamente, o proxy funciona como um intermediador entre o cliente e o servidor. Sua tarefa é basicamente pegar pacotes transmitidos do servidor para o cliente e retirar o seu cabeçalho, inserindo outro ou nenhum. Serve para aumentar a velocidade das conexões, descartando pacotes repetidos ou que contém informações já presentes no terminal cliente.
101
Figura 34: Comparação entre UDP, MMTP e máxima teórica para pacotes versus periodicidade.
102
Figure 35: Pacotes recebidos após seus prazos
À exceção das perdas causadas por erros nos meios, quando a periodicidade chega a 35000
microssegundos, o canal agregado criado pelo MMTP tem largura de banda suficiente para carregar
todo o tráfego. Isto não é verdade para nenhuma conexão utilizando apenas um canal de
transmissão. Isso significa que mesmo no seu presente estado, o MMTP possibilita um fluxo de
melhor qualidade e maior confiabilidade do que qualquer conexão que utiliza apenas um canal.
Mais informações sobre o MMTP podem ser obtidas em [5] e [31].
103
Capítulo 8 8. Desenvolvimento do Software de Streaming O trabalho realizado tem como objetivo a “junção” do programa de player de MPEG desenvolvido
por [20] com o protocolo MMTP e analisar a sua performance. A estrutura básica se baseia na idéia
de cliente-servidor [21]. Em resumo, um terminal opera integralmente, esperando pedidos da rede, e
o outro realiza o pedido pela rede, requisitando o serviço. Nossa idéia é estruturar um sistema de
servidor de arquivos MPEG em tempo real e um cliente para recebê-los e exibi-los.
8.1 Primeira fase do projeto Primeiramente, foi feito um estudo sobre o programa original e o separamos em dois programas
independentes. O primeiro tinha a finalidade de ser o servidor de imagens, ou seja, aquele que lê o
arquivo de vídeo, separa em quadros e envia para uma saída. No caso, a primeira saída utilizada foi
o próprio descritor “stdout” do sistema operacional LINUX. O segundo, tinha a finalidade de
trabalhar como o cliente. Ele recebia os quadros via o descritor “stdin” e os exibia na tela, conforme
fazia o programa original. Nesta etapa, o trabalho realizado foi bem simples. Duas cópias do
programa original foram utilizadas. No primeiro, com o objetivo de preparar o software do cliente,
alteramos a forma como ele lia o arquivo do disco, modificando o arquivo “readfile.c”. Neste
arquivo se encontra a função “get_more_data” que por sua vez, utiliza a função
“pure_get_more_data”, como pode ser visto abaixo:
int
get_more_data(vid_stream)
VidStream *vid_stream;
{
unsigned int **bs_ptr=&vid_stream->buf_start;
int *max_length=&vid_stream->max_buf_length;
int *length_ptr=&vid_stream->buf_length;
unsigned int **buf_ptr=&vid_stream->buffer;
int ioBytes, data, result;
unsigned char byte;
unsigned int *mark;
int sys_layer= vid_stream->sys_layer;
if (sys_layer == 0) {
return (*bs_ptr,
*max_length,
length_ptr,
buf_ptr,
vid_stream);
}
104
if (sys_layer == -1) {
/* Inicialização */
vid_stream->swap = (htonl(1) != 1);
mark = *bs_ptr;
ioBytes = fread(&data, 1, 4, vid_stream->input);
if (ioBytes != 4) {
return 0;
}
data = ntohl(data);
if ( (data == PACK_START_CODE) || (data == SYSTEM_HEADER_START_CODE) ) {
got_sys:
/* Problema, uma camada de sistema MPEG no Stream . Mais difícil de “quebrar”. Chama o especialista (função read_sys).... */
fprintf(stderr,"This is an MPEG System Layer Stream. ");
fprintf(stderr,"Audio is not played.\n");
vid_stream->sys_layer = 1;
result = read_sys(vid_stream,(unsigned int) data);
return result;
} else if (data == SEQ_START_CODE) {
got_seq:
/* Sem “lixo” de camada de sistema. Finja que não olhou e daqui para frente chame pure_get_more_data */
vid_stream->sys_layer = 0;
**bs_ptr = data;
*length_ptr = 1;
result = pure_get_more_data(*bs_ptr, *max_length,
length_ptr, buf_ptr, vid_stream);
*buf_ptr = *bs_ptr;
return result;
} else {
int state;
fprintf(stderr, "Lixo no início da stream, procurando pelo start code\n");
state = 0;
while (TRUE) {
if ((ioBytes = fread(&byte, 1, 1, vid_stream->input)) != 1) return 0;
if (byte == 0) {
if (state < 2) state++;
} else if ((byte == 1) && (state == 2)) {
state++;
} else {
state = 0;
}
if (state == 3) {
if ((ioBytes = fread(&byte, 1, 1, vid_stream->input)) != 1) return 0;
data = ((unsigned int) byte + 0x100);
switch (data) {
case SEQ_START_CODE:
goto got_seq;
case PACK_START_CODE:
case SYSTEM_HEADER_START_CODE:
goto got_sys;
default:
/* keep looking */
105
state=0;
}
}
}}
}
/* Um camada de sistema no stream (chamada pela primeira vez, chama o especialista */
result = read_sys(vid_stream,0);
return result;
}
A função “get_more_data” tem o propósito de ler o arquivo de vídeo MPEG do disco, carregando o
buffer de memória. Além disso ele analisa a presença de camada de sistema no bitstream (na
seqüência de bits), ou seja, ele retorna a presença ou não a presença de áudio multiplexado com o
vídeo. Se houver, ele chamará a função “read_sys”, que separa o áudio do vídeo. Deve-se ressaltar
mais uma vez que o processo de separação tem como intuito apenas retirar o áudio sem processá-lo.
A análise de função “read_sys”, também chamada de especialista, foge ao escopo do trabalho. Se
não houver, ele usa a função “pure_get _more_data” para ler somente o arquivo de vídeo:
int pure_get_more_data(buf_start, max_length, length_ptr, buf_ptr, vid_stream)
unsigned int *buf_start;
int max_length;
int *length_ptr;
unsigned int **buf_ptr;
VidStream *vid_stream;
{
int length, num_read, i;
unsigned int request;
unsigned char *buffer, *mark;
unsigned int *lmark;
BOOLEAN swap=vid_stream->swap;
if (vid_stream->EOF_flag) return 0;
length = *length_ptr;
buffer = (unsigned char *) *buf_ptr;
if (length > 0) {
memcpy((unsigned char *) buf_start, buffer, (unsigned int) (length*4));
mark = ((unsigned char *) (buf_start + length));
}
else {
mark = (unsigned char *) buf_start;
length = 0;
}
request = (max_length-length)*4;
num_read = fread(mark, 1, request, vid_stream->input);
106
/* Paulo Villegas - 26/1/1993: Correction for 4-byte alignment */
{
int num_read_rounded;
unsigned char *index;
num_read_rounded = 4*(num_read/4);
/* isso pode ocorrer apenas se num_read<request; i.e. alcançou o fim do arquivo */
if ( num_read_rounded < num_read ) {
num_read_rounded = 4*( num_read/4+1 );
/* fill in with zeros */
for( index=mark+num_read; index<mark+num_read_rounded; *(index++)=0 );
/* advance to the next 4-byte boundary */
num_read = num_read_rounded;
}
}
if (num_read < 0) {
return -1;
} else if (num_read == 0) {
*buf_ptr = buf_start;
/* Faz 32 bits após o fim igual a 0 e 32 * bits após isso igual ao “seq end code” * com o objetivo de evitar dados bagunçados de uma recursão infinita*/
*(buf_start + length) = 0x0;
*(buf_start + length+1) = SEQ_END_CODE;
vid_stream->EOF_flag = 1;
return 0;
}
lmark = (unsigned int *) mark;
num_read = num_read/4;
if (swap) {
for (i = 0; i < num_read; i++) {
*lmark = htonl(*lmark);
lmark++;
}
}
*buf_ptr = buf_start;
*length_ptr = length + num_read;
return 1;
}
/*
Aqui está o especialista....
O código é adaptado de um outro programa demux ....
*/
107
Após uma análise minuciosa do programa, foi possível a localização de tais pontos de acesso ao
arquivo de vídeo para a sua exibição. Isso era feito através de uma função utilitária chamada
“correct_underflow” (especificada em “util.c”). Essa função é requisitada freqüentemente ao
longo da decodificação do vídeo e para tanto, utiliza as duas funções descritas acima. Foi verificado
que sempre que o programa precisava preencher o buffer de memória, ele chamava
“correct_underflow”. As modificações preliminares foram feitas apenas modificando o comando
“fread”, que lia do arquivo original, para “fdread” que lê do descritor “stdin”, nas funções
“get_more_data” e “pure_get_more_data”. Assim, o cliente carregaria o buffer de vídeo
diretamente de “stdin”. Mantendo o restante do programa, ele continuaria a exibir o vídeo
normalmente. Ou seja, carregando o buffer com os dados corretos, ele pode seguir o procedimento
de decodificação e exibição.
Na segunda cópia, com o objetivo de preparar o software do servidor. Ele tinha que ler o arquivo
do disco, realizar o parsing do bitstream, isto é, dividir os dados em pacotes, cada um contendo um
quadro de vídeo. Tal mudança foi feita da seguinte maneira:
1. Na função “get_more_data” foi mantido “fread” para ler os dados do arquivo de vídeo do
disco.
2. Esses dados armazenados no buffer passavam pelo processo de parsing realizado pelo
programa em outras funções.
3. Após o parsing, era identificado no quadro lido o “frame start code”, que indica o início do
quadro. Isso ocorre quando o programa principal “main.c” chama a função “mpegVidRsrc”
localizada no arquivo “vídeo.c”.
4. Nesta função, os dados lidos eram escritos no descritor “stdout”.
5. As tentativas seguintes, realizadas pelo programa, para exibir os quadros foram suprimidas,
de forma que o programa servidor apenas carregaria os quadros no buffer e os gravaria em
“stdout” para o acesso do cliente.
Contudo, neste ponto do nosso trabalho constatamos que o servidor não estava realizado o processo
de parsing corretamente. Na verdade, ele não distinguia os quadros individuais, gravando os dados
do buffer, em sua totalidade no “stdout”. Certamente, para os propósitos de visualização e teste o
programa funcionava corretamente. O problema do particionamento não era adequado para a
proposta de transmissão dos pacotes via protocolo UDP [32].
108
8.2 Segunda fase do projeto Para o cliente, a única mudança em relação ao que foi feito acima, foi a troca da origem da leitura
dos dados. Agora, o programa passaria a ler os dados a partir do socket UDP e não mais do “stdin”.
Isso foi feito trocando-se nas funções get_more_data e pure_get_more_data, o comando fdread por
UdpRecv. O uso de tal comando, criado e utilizado pelo protocolo MMTP [5] requer ser
inicializado no programa main. Sua especificação se encontra no arquivo net.c:
int UdpRecv(unsigned char * buf, int len, int interf)
{
int rc;
unsigned int send_addr_len;
struct sockaddr send_addr;
// printf("receiving an UDP packet... \n");
send_addr_len = sizeof(struct sockaddr);
rc = recvfrom(mtpSock[interf],(char *)buf,len,0,
(struct sockaddr *)&send_addr,&send_addr_len);
//printf("packet received\n");
if (rc < 0)
{
fprintf(stderr,"network: failed in recvfrom rc = %d.Exiting...\n",rc);
fprintf(stderr,"Exiting...\n");
return(0);
}
return rc;
}
Os parâmetros de entrada da função são:
• char *buf � ponteiro que indica aonde será gravado o dado a ser recebido pelo socket;
• int len � quantidade de bytes que serão lidos do socket;
• int interface � número que identifica a interface de rede a ser utilizada (cada número,
começando de 0, é associado a uma interface através do arquivo params.txt que será visto
abaixo, por exemplo 0 indica a primeira interface especificada no arquivo).
Por sua vez, as funções descritas em net.c necessitam de dois outros arquivos: defs.h e params.c. O
primeiro estabelece definições de estruturas utilizadas pelo protocolo UDP, mais informações sobre
tais estruturas podem ser encontradas em [32]. O segundo é um arquivo criado também para uso do
protocolo MMTP. Ele tem uma função chamada ReadParams que tem o objetivo de ler um arquivo
chamado params.txt, preenchido pelo usuário. Neste arquivo, encontram-se de maneira ordenada,
109
informações necessárias para o processo de comunicação UDP, e informações específicas utilizadas
pelo MMTP. Abaixo está um exemplo do preenchimento de um arquivo params.txt para apenas
uma duas interfaces (a da máquina local e a da máquina destino):
# esse é o arquivo de parâmetros
#
# todos os comentários devem começar com #
#
# nenhuma linha pode ser maior do que 80 caracteres
#
#
# número de interfaces disponíveis
2
# início da primeira interface # taxa da primeira interface (em microssegundos)
20000000
# latência da primeira interface
20
# nome da interface local para este enlace
eth0
# endereço ip da máquina remota para a primeira interface
127.0.0.1
# endereço da porta UDP para a máquina local
1501
# endereço da porta UDP para a máquina remota
1500
# fim da primeira interface
# início da segunda interface # taxa da primeira interface (em microssegundos)
20
# latência da primeira interface
20
# nome da interface local para este enlace
eth0
# endereço ip da máquina remota para a primeira interface
127.0.0.1
# endereço da porta UDP para a máquina local
1701
# endereço da porta UDP para a máquina remota
1700
As informações necessárias para a comunicação via UDP são: endereço da máquina a qual deseja-
se conectar (máquina remota), porta UDP da máquina local e porta UDP da máquina que se deseja
conectar. As demais informações como interface local, taxa de transmissão e latência da primeira
interface em microssegundos são informações utilizadas pelo MMTP.
Portanto, o cliente agora lê do socket e armazena os dados no buffer para serem processadas.
Quando o buffer é esvaziado, o programa chama novamente a função get_more_data para um novo
preenchimento.
110
Quanto ao servidor, foi criado um outro programa em paralelo ao que estava sendo utilizado. Neste
programa podemos definir os seguintes passos:
1. O arquivo MPEG é lido da fonte local.
2. O cabeçalho do arquivo MPEG, é enviado através da função UdpSend.
3. Realiza o processo de parsing, quebrando o bitstream em quadros distintos.
4. Envia esses quadros através de UdpSend.
A função UdpSend também é especificada no arquivo net.c, pois também foi criada para ser
utilizada pelo protocolo MMTP. Seu código se encontra abaixo:
int UdpSend(unsigned char * buf, int len, int interf)
{
int rc=0;
struct sockaddr_in send_addr;
struct timeval t;
// int j;
send_addr.sin_family = AF_INET;
send_addr.sin_addr.s_addr = remoteMachine[interf];
send_addr.sin_port = htons(remotePort[interf]);
// printf ("Sending to remote_machine::%d \n",remotePort[interf]);
//simulando perdas...
// j=1+(int) (10.0*rand()/(RAND_MAX+1.0));
// if (j>1)
// para inserir perdas retire os comentários das duas linhas acima
rc = sendto(mtpSock[interf],(char *)buf,len,0,
(struct sockaddr *)&send_addr,sizeof(struct sockaddr));
// else printf("(did not send)");
if (rc < 0)
{
fprintf(stderr,"network: failed in sendto rc = %d.Exiting...\n",rc);
exit(-1);
}
return rc;
}
Os parâmetros de entrada da função são:
• char *buf � ponteiro que indica de onde será lido o dado a ser enviado pelo socket;
• int len � quantidade de bytes que serão enviados pelo socket;
• int interface � número que identifica a interface de rede a ser utilizada.
111
Deve-se ressaltar que o servidor não apresenta o vídeo, ele apenas realiza as funções descritas acima
e as envia para o cliente. A apresentação do vídeo será tarefa do programa cliente.
Abaixo temos o código do programa servidor que funcionará em conjunto com o sender do MMTP:
#include<stdio.h>
#include<sys/time.h>
#include "defs.h"
/* Start codes. */
#define SEQ_END_CODE 0x000001b7
#define SEQ_START_CODE 0x000001b3
#define GOP_START_CODE 0x000001b8
#define PICTURE_START_CODE 0x00000100
#define SLICE_MIN_START_CODE 0x00000101
#define SLICE_MAX_START_CODE 0x000001af
#define EXT_START_CODE 0x000001b5
#define USER_START_CODE 0x000001b2
#define SEQUENCE_ERROR_CODE 0x000001b4
#define TAM_BUFF 1000000 //Tamanho maximo do Buffer de leitura do arquivo de video
int main(int argc, char *argv[]){
int GOP;
FILE *arq;
int i;
int state;
unsigned int frame;
int buf_len;
unsigned char buffer[TAM_BUF];
int p, inicio;
struct timeval tv,old,now;
GOP = 0;
state = 0;
arq = fopen(argv[1],"r");
if (arq == NULL) {
printf("\n Falha ao abrir arquivo!!\n");
exit(1);
}
ReadParams();
gettimeofday(&old,NULL);
p = 0;
buf_len = fread(&buffer[p],1,TAM_BUF,arq);
printf("\n Leu %d do arq.",buf_len);
UdpSend("Inicio",7,0); // lixo qualquer para acordar o MMTP
printf("\n...inicializando.");
inicio = p;
do{ // aqui faz a busca pelo start code
switch (state)
{
case 0:
if (buffer[p] == 0x00) state++;
break;
112
case 1:
if (buffer[p] == 0x00) state++;
else {
state = 0;
}
break;
case 2:
if (buffer[p] == 0x01) state++;
else if (buffer[p] != 0x00) state = 0;
break;
case 3:
if (buffer[p] == 0x00)
{
i = UdpSend(&buffer[inicio],(p-inicio)-3,0);
inicio = p-3;
printf("\nEnviando...%d ",i);
printf("sc = %d %d %d
%d",buffer[inicio],buffer[inicio+1],buffer[inicio+2],buffer[inicio+3]);
state = 0; // comeca nova seq
tv.tv_sec = 0;
tv.tv_usec = period[0]; // tempo de espera entre os frames em microsegundos (definidos no arquivo params.txt)
select(0,NULL,NULL,NULL,&tv);
}
else state = 0;
break;
}
p++;
if (p == buf_len) //chegou no limite do buffer - recarrega o buffer
{
p = buf_len-inicio;
printf(" \n p = %d",p);
memcpy(&buffer[0],&buffer[inicio],p);
inicio = 0;
buf_len = fread(&buffer[p],1,TAM_BUF-p,arq);
p--;
if (buf_len)
printf("\n (carregando buffer de memoria) %d",buf_len);
}
}while (p < buf_len);
i = UdpSend(&buffer[inicio],(p-inicio),0); // envia bytes finais
printf("\nEnviando...%d\n",i);
fclose(arq);
printf("\n * Fim *\n");
UdpSend("Fim",3,0); //finaliza transmissao (para o writetest-RecFile)
}
113
Por último foram feitas modificações no próprio protocolo MMTP de forma que ele fosse capaz de
trabalhar com arquivos MPEG reais ao invés de simples simulações.
No lado do servidor (sender.c), o código abaixo foi incluído no protocolo para analisar os bits do
cabeçalho de cada quadro recebido, identificando o tipo de quadro (I, P ou B) e atribuindo a
respectiva prioridade aos pacotes relacionados (0, 1 ou 2). Dessa forma, cada pacote enviado pelo
sender terá durante a transferência uma prioridade específica de acordo com o tipo de quadro de
qual faz parte.
x = UdpRecv((unsigned char *) buffer, MAXFRAMESIZE, 0);
size = x; // para o sender enviar o tamanho correto do quadro em bytes
// (detecta tipo de frame) int frametype; //4 bytes de startcode
// -> 10 bits de informacao temporal // -> 3 bits tipo de frame
frametype = (buffer[5] & 0x38)/8; // pega 3 bits do sexto byte
switch (frametype)
{
case 1:
printf("\n---(Frame I)");
prio = 0; // Frame I
break;
case 2:
printf("\n---(Frame P)");
prio = 1; // Frame P
break;
case 3:
printf("\n---(Frame B)");
prio = 2; // Frame B
break;
}
if (frametype > 4)
{ prio = 2;
printf("\n---(Frame ??)");
}
if (first) //Para grantir que o primeiro pacote (seq headers) { // tenha prioridade maxima
prio = 0;
first--;
}
114
Por fim, no lado do cliente (receiver.c), o código do MMTP sofreu modificações na função
process_data para que fosse capaz de reconstruir um quadro quando todos os pacotes referentes a
este, estivessem presentes na fila de chegada. E quando tiver um quadro completo enviar, também
via UDP, para o programa cliente mpeg_play de exibição de vídeo. Como mostrado abaixo:
if (complete){
temp = 0;
for (i=0;i<x;i++)
{
if (i == x) // busca todas as partes do quadro e // grava de forma ordenada em um buffer de saída
memcpy(&buffer[DATASIZE*(i-1)],
Queue[(y+i)%MAXQSIZE].data,Packet->size%DATASIZE);
else
memcpy(&buffer[DATASIZE*(i-1)],
Queue[(y+i)%MAXQSIZE].data,DATASIZE);
}
if (Packet->deadline > (tick+starttime))
{
temp = UdpSend(&buffer[0],Packet->size,0);
printf("\n****---Enviando (%d) pro mpeg_play ***",temp);
printf("frame %5d received at time %6d,
deadline %6d\n", Packet->frame, tick, Packet->deadline);
}
else
printf("frame %5d is late -> time %6d,
deadline %6d\n", Packet->frame, tick, Packet->deadline);
}
}
else
{
last = Packet->size % DATASIZE;
if (last < 1)
last = Packet->size - DATASIZE;
else
last = Packet->size - last;
if (Packet->pos == last)
{
// full frame, check if all pieces are in
printf("received last element of frame\n");
x = Packet->size / DATASIZE;
if (Packet->size % DATASIZE)
x++;
y = y - x + MAXQSIZE;
complete = 1;
for (i=1;i<=x;i++)
{
if (!(sent[(y+i)%MAXQSIZE]) ||
(Queue[(y+i)%MAXQSIZE].seq != (Packet->seq - x + i)))
115
complete=0;
}
if (complete)
{
//Fernando
temp = 0;
for (i=1;i<=x;i++)
{
if (i == x)// || (Packet->size < DATASIZE))
// se for o ultimo ou unico pacote
memcpy(&buffer[DATASIZE*(i-1)],
Queue[(y+i)%MAXQSIZE].data,Packet->size%DATASIZE);
else
// grava com tamanho DATASIZE (1400) se nao for o ultimo
memcpy(&buffer[DATASIZE*(i-1)],
Queue[(y+i)%MAXQSIZE].data,DATASIZE);
}
if (Packet->deadline > (tick+starttime))
{
// Envia o buffer de saída pro mpeg_play
temp = UdpSend(&buffer[0],Packet->size,0);
printf("\n****---Enviando (%d) pro mpeg_play ***",temp);
printf("frame %5d (%d bytes) received at time %6d, deadline
%6d\n", Packet->frame, Packet->size , tick, Packet->deadline);
}
else
printf("frame %5d is late -> time %6d, deadline %6d\n",
Packet->frame, tick, Packet->deadline);
// se o tempo esgotou, descarta quadro
}
}
}
}
}
else
printf("Packet %3d is late. Deadline: %6d, now: %6d\n",
Packet->seq, Packet-> deadline, tick);
}
116
Capítulo 9
9. Considerações finais
9.1 Utilização do software e experimento
Sendo ainda apenas um protótipo, a utilização do software não é muito intuitiva nem flexível, logo,
convém seguir os seguintes procedimentos adotados no experimento:
O software é composto de quatro executáveis que devem rodar em processos distintos no sistema.
Dois em cada máquina. Parse e Sender em uma, Receiver e Mpeg_play na outra.
Os programas conversam entre si da seguinte forma:
Primeiramente o receiver recebe uma mensagem do sender e é feito um handhsake entre os dois, depois o parse lê o arquivo de vídeo mpeg e começa a enviar ao sender (via UDP) os quadros de vídeo. O sender encapsula esses quadros no protocolo MMTP e os envia ao receiver na máquina cliente. O receiver recupera o quadro completo e envia ao mpeg_play (via UDP) para exibição.
Os programas ficaram divididos dessa forma para facilitar a comparação dos testes feitos com MMTP (os quatro funcioanndo juntos) e com UDP puro (sem MMTP).
Quadros de vídeo mpeg (sem MMTP)
Parse (UDP) Sender (MMTP) Receiver (UDP) Mpeg_Play
Quadros de vídeo mpeg
Quadros de vídeo mpeg
Pacotes de controle-mmtp e dados
Pacotes de controle do mmtp
117
No formato em que estão, é muito importante que os programas sejam executados na ordem correta.
Isto é, primeiro na máquina cliente, o mpeg_play, depois o receiver. Em sequida, na máquina
servidora, o sender e por último o parse.
Outro detalhe importante é o arquivo de configurações “params.txt”. Todos os quatro programas
possuem o seu, e por isso cada programa deve ser executando em um diretório distinto e com o seu
params.txt configurado de acordo. Configurar o params.txt significa dizer que porta UDP o
programa está utilizando e com que porta e endereço ele vai se comunicar, e ainda outras
configurações mais específicas para cada programa, como a taxa de trasnferência do mmtp e
latência da linha, ou o intervalo de tempo entre cada quadro enviado pelo parse.
Resultados obtidos Vários arquivos de vídeo de diferentes tamanhos e taxas de compressão foram utilizados em testes,
mas para simplificação colocamos aqui o menor deles (ts.mpeg), que é um vídeo de 30Kb e 1
segundo de duração.
Esses resultados foram obtidos utilizando o MMTP através de uma rede Fast Ethernet sem tráfego extra. Expomos tais resultados no apêndice, ao final do trabalho.
9.2 Conclusão e trabalhos futuros À primeira vista, os testes mostraram maior eficiência em termos de continuidade de fluxo para o
protocolo UDP, pelo menos em uma rede local. Não foi possível, ainda verificar a eficácia do programa
rodando na internet. Nos testes acima relatados, todos feitos em uma rede, tínhamos que considerar a
ausência de elementos como filas e fluxos de pacotes concorrentes.
Certamente, nesse ambiente teórico perfeito, o MMTP apresenta um baixo rendimento, já que foi
construído para trabalhar com situações adversas, oferecendo uma continuidade que o protocolo UDP
somente não oferece.
Contudo, o MMTP demonstrou um funcionamento coerente ao analisar ausência de jitter e aumentar a
taxa gradativamente (verificar resultados na seção anterior). À medida que os quadros eram enviados, o
fluxo de vídeo começava a acelerar. Outro fato que deve ser considerado são as limitações impostas
pelo próprio Kernel do Linux [32] que possui um clock limitado. O MMTP ao verificar uma rede
totalmente sem retardos de propagação envia os quadros a taxas cada vez maiores e com intervalos
cada vez menores. Tal fato impõe um condição não prevista pelo kernel, que ao funcionar em com um
clock limitado, começa a receber quadros acima da sua capacidade de processamento e começa a
descartar. Para evitar o descarte, a velocidade do MMTP tem que ser reduzida. O procedimento para
tanto é simplesmente alterando o parâmetro taxa da interface no arquivo de configuração params.txt.
Assim, ainda há a necessidade de testarmos o MMTP na internet e comparar os resultados gerados com
o programa funcionando somente com o UDP. Graças ao retorno de informações fornecido pelo
protocolo, será possível gerarmos gráficos comparativos e comprovarmos a eficácia do protocolo.
Como já fora dito, o protótipo ainda não processa som, devido a limitações do projeto que utilizamos
como base, que foi o Mpeg_play de Berkeley. A título de trabalhos futuros, propomos o processamento
dos fluxos de áudio e sua incorporação no processo de quebra (parsing) e envio no MMTP. Estudos
mais aprofundados sobre o assunto deverão ser realizados.
119
Outra proposta que temos para a continuação do trabalho é a implementação do protótipo em Java. A
grande vantagem disso seria, além de não ser uma linguagem proprietária, a portabilidade do software
do cliente8. A linguagem Java nos oferecerá a possibilidade de execução do software em qualquer
sistema operacional, desde que este tenha instalado uma máquina virtual Java [37]. Quanto ao servidor,
não temos ainda o interesse em implementarmos em Java, visto que a maioria dos servidores
atualmente em utilização funcionam sobre plataforma Linux.
Por fim, deveremos instituir ainda a arquitetura cliente-servidor, onde o cliente faz o pedido e o
servidor aguarda passivamente. Atualmente, o servidor realiza o envio do arquivo desejado e o cliente
apenas exibe. Tal modificação se mostra a menor de todas em vista da sua facilidade, mas é de
relevância deste trabalho que seja comentada.
8 Software cliente: tal expressão refere-se aos já comentados receiver e mpeg_play. Por enquanto são dois programas independentes que devem funcionar em conjunto na recepção, da mesma forma que temos o parser e o sender na transmissão.
120
Apêndice – Resultado experimental (vide 9.1) Parse
s: # arquivo de parametros
s: # do parse_serv
s: #
s: # all comments lines should begin with #
s: # no line should be longer than 80 chars
s: #
s: # number of available interfaces
s: 1
s: # begin first interface
s: # tempo de espera entre pacotes em microsegundos
s: 300000
s: # latency first interface
s: 20
interface: ^eth0^
s: # ip address (localhost) MMTP-Sender
s: 127.0.0.1
Remote Machine 100007f
s: # UDP port address for the local machine
s: 1500
Remote Port: 1501
Leu 30014 do arq.
Enviei 7 bytes de inicio
Enviando...40
Enviando...11774
Enviando...6265
Enviando...757
Enviando...823
Enviando...665
Enviando...6312
Enviando...914
Enviando...893
Enviando...878
Enviando...692
* Fim *
MMTP: The sender!
s: # arquivo de parametros
s: # do MMTP - Sender
s: #
s: # all comments lines should begin with #
s: # no line should be longer than 80 chars
s: #
s: # number of available interfaces
s: 2
121
s: # begin first interface
s: # rate for the first interface (nao eh usado)
s: 600
s: # latency first interface (nao eh usado)
s: 20
interface: ^eth0^
s: # ip address (localhost) - parse_serv
s: 127.0.0.1
Remote Machine 100007f
s: # UDP port address for the local machine
s: 1501
Remote Port: 1500
s: # end first interface
s: # begin second interface
s: # rate for the second interface
s: 100
s: # latency second interface
s: 20
interface: ^eth0^
s: # ip address for the peer machine for the first interface
s: 127.0.0.1
Remote Machine 100007f
s: # UDP port address for the local machine
s: 1701
Remote Port: 1700
Using 2 channels
sending first packet on line 1
sending second packet on line 1
Receiving initial packets
Received first packet, line 1
Receiving initial packets
Received second packet, line 1 period: 20
Data is available now.
---(Frame ??)priority 0, received 7 bytes and x = 7
size = 7, head = 0, sizeQ = 0
tail 0
How long we have: 1424
We have to send 1 packets in this time
We can send 71 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
priority 0, received 40 bytes and x = 40
size = 40, head = 0, sizeQ = 1
tail 1
How long we have: 2024
We have to send 2 packets in this time
We can send 101 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
---(Frame I)priority 0, received 11774 bytes and x = 11774
size = 11774, head = 0, sizeQ = 2
tail 2
122
size = 10374, head = 0, sizeQ = 3
tail 3
size = 8974, head = 0, sizeQ = 4
tail 4
size = 7574, head = 0, sizeQ = 5
tail 5
size = 6174, head = 0, sizeQ = 6
tail 6
size = 4774, head = 0, sizeQ = 7
tail 7
size = 3374, head = 0, sizeQ = 8
tail 8
size = 1974, head = 0, sizeQ = 9
tail 9
size = 574, head = 0, sizeQ = 10
tail 10
How long we have: 2594
We have to send 9 packets in this time
We can send 129 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
--------------------------------------------------------------------
Data is available now.
---(Frame P)priority 1, received 6265 bytes and x = 6265
size = 6265, head = 0, sizeQ = 11
tail 11
size = 4865, head = 0, sizeQ = 12
tail 12
size = 3465, head = 0, sizeQ = 13
tail 13
size = 2065, head = 0, sizeQ = 14
tail 14
size = 665, head = 0, sizeQ = 15
tail 15
How long we have: 3164
We have to send 14 packets in this time
We can send 226 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
sending packet 2 (2) on line 1
sending packet 3 (3) on line 1
---(Frame B)priority 2, received 757 bytes and x = 757
size = 757, head = 0, sizeQ = 16
tail 16
How long we have: 3734
We have to send 13 packets in this time
We can send 266 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
123
Data is available now.
sending packet 4 (4) on line 1
sending packet 5 (5) on line 1
sending packet 6 (6) on line 1
---(Frame B)priority 2, received 823 bytes and x = 823
size = 823, head = 0, sizeQ = 17
tail 17
How long we have: 4304
We have to send 11 packets in this time
We can send 307 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
---(Frame B)priority 2, received 665 bytes and x = 665
size = 665, head = 0, sizeQ = 18
tail 18
How long we have: 4874
We have to send 10 packets in this time
We can send 348 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
--------------------------------------------------------------------
Data is available now.
sending packet 9 (9) on line 1
sending packet 10 (10) on line 1
sending packet 11 (11) on line 1
---(Frame P)priority 1, received 6312 bytes and x = 6312
size = 6312, head = 0, sizeQ = 19
tail 19
size = 4912, head = 0, sizeQ = 20
tail 20
size = 3512, head = 0, sizeQ = 21
tail 21
size = 2112, head = 0, sizeQ = 22
tail 22
size = 712, head = 0, sizeQ = 23
tail 23
How long we have: 5444
We have to send 12 packets in this time
We can send 604 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
sending packet 12 (12) on line 1
---(Frame B)priority 2, received 914 bytes and x = 914
size = 914, head = 0, sizeQ = 24
tail 24
How long we have: 6014
124
We have to send 10 packets in this time
We can send 668 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
--------------------------------------------------------------------
Data is available now.
sending packet 15 (15) on line 1
sending packet 16 (16) on line 1
sending packet 17 (17) on line 1
sending packet 18 (18) on line 1
---(Frame B)priority 2, received 893 bytes and x = 893
size = 893, head = 0, sizeQ = 25
tail 25
How long we have: 6584
We have to send 5 packets in this time
We can send 1097 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
--------------------------------------------------------------------
Data is available now.
sending packet 21 (21) on line 1
sending packet 22 (22) on line 1
sending packet 23 (23) on line 1
sending packet 24 (24) on line 1
---(Frame B)priority 2, received 878 bytes and x = 878
size = 878, head = 0, sizeQ = 26
tail 26
How long we have: 7154
We have to send 2 packets in this time
We can send 1430 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
---(Frame B)priority 2, received 692 bytes and x = 692
size = 692, head = 0, sizeQ = 27
tail 27
How long we have: 7724
We have to send 1 packets in this time
We can send 1544 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
---(Frame B)priority 2, received 3 bytes and x = 3
size = 3, head = 0, sizeQ = 28
125
tail 28
How long we have: 8324
We have to send 2 packets in this time
We can send 1664 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
--------------------------------------------------------------------
Data is available now.
sending packet 27 (27) on line 1
sending packet 28 (28) on line 1
---(Frame ??)priority 0, received 7 bytes and x = 7
size = 7, head = 0, sizeQ = 29
tail 29
How long we have: 8001
We have to send 1 packets in this time
We can send 1600 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
*** keep alive packet ***--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
126
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
--------------------------------------------------------------------
Data is available now.
priority 0, received 40 bytes and x = 40
size = 40, head = 0, sizeQ = 30
tail 30
How long we have: 8601
We have to send 2 packets in this time
We can send 1720 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
sending packet 29 (29) on line 1
sending packet 30 (30) on line 1
---(Frame I)priority 0, received 11774 bytes and x = 11774
size = 11774, head = 0, sizeQ = 31
tail 31
size = 10374, head = 0, sizeQ = 32
tail 32
size = 8974, head = 0, sizeQ = 33
tail 33
size = 7574, head = 0, sizeQ = 34
tail 34
size = 6174, head = 0, sizeQ = 35
tail 35
size = 4774, head = 0, sizeQ = 36
tail 36
size = 3374, head = 0, sizeQ = 37
tail 37
size = 1974, head = 0, sizeQ = 38
tail 38
size = 574, head = 0, sizeQ = 39
tail 39
How long we have: 9171
We have to send 9 packets in this time
We can send 1834 packets in this time
127
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
sending packet 31 (31) on line 1
sending packet 32 (32) on line 1
sending packet 33 (33) on line 1
sending packet 34 (34) on line 1
sending packet 35 (35) on line 1
sending packet 36 (36) on line 1
---(Frame P)priority 1, received 6265 bytes and x = 6265
size = 6265, head = 0, sizeQ = 40
tail 40
size = 4865, head = 0, sizeQ = 41
tail 41
size = 3465, head = 0, sizeQ = 42
tail 42
size = 2065, head = 0, sizeQ = 43
tail 43
size = 665, head = 0, sizeQ = 44
tail 44
How long we have: 9741
We have to send 8 packets in this time
We can send 1948 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
sending packet 37 (37) on line 1
sending packet 38 (38) on line 1
sending packet 41 (41) on line 1
sending packet 42 (42) on line 1
---(Frame B)priority 2, received 757 bytes and x = 757
size = 757, head = 0, sizeQ = 45
tail 45
How long we have: 10311
We have to send 3 packets in this time
We can send 2062 packets in this time
We are dropping anything with priority greater than 2
--------------------------------------------------------------------
Data is available now.
testing other lines
receive frame
change rate request
--------------------------------------------------------------------
Data is available now.
sending packet 43 (43) on line 1
---(Frame B)priority 2, received 823 bytes and x = 823
size = 823, head = 0, sizeQ = 46
tail 46
How long we have: 10881
We have to send 1 packets in this time
We can send 2176 packets in this time
We are dropping anything with priority greater than 2
128
MMTP: The receiver!
s: # arquivo de parametros
s: # do MMTP-Receiver
s: #
s: # all comments lines should begin with #
s: # no line should be longer than 80 chars
s: #
s: # number of available interfaces
s: 2
s: # begin first interface
s: # rate for the first interface (nao eh usado)
s: 600
s: # latency first interface (nao eh usado)
s: 20
interface: ^eth0^
s: # ip address (localhost) - mpeg_play
s: 127.0.0.1
Remote Machine 100007f
s: # UDP port address for the local machine
s: 1550
Remote Port: 1551
s: # end first interface
s: # begin second interface
s: # rate for the second interface
s: 100
s: # latency second interface
s: 20
interface: ^eth0^
s: # ip address for the peer machine for the first interface
s: 127.0.0.1
Remote Machine 100007f
s: # UDP port address for the local machine
s: 1700
Remote Port: 1701
Using 2 channels
handshake
starting main program
ack probe
received the first probe for line 1 at 242
--------------------------------------------------------------------
ack probe 2
received the second probe for line 1 at 242 -> period: 20
--------------------------------------------------------------------
last received 0
packet last sent 0
Probe packet 0
Packet 0 received Deadline: 600, now: 442
Line 1 -> interarrival = 442, jitter = 242
--------------------------------------------------------------------
last received 0
packet last sent 0
Probe 2 - packet 1
129
Packet 1 received Deadline: 1200, now: 442
received last element of frame
****---Enviando (40) pro mpeg_play ***frame 1 (40 bytes) received at time 442, deadline 1200
measured delay for line 1 --> 0: 2
New rate line 1: 14
period 100
--------------------------------------------------------------------
last received 1
packet last sent 1
Data packet 2 was received
Packet 2 received Deadline: 1800, now: 482
Line 1 -> interarrival = 40, jitter = 0
--------------------------------------------------------------------
last received 2
packet last sent 2
Data packet 3 was received
Packet 3 received Deadline: 1800, now: 496
Line 1 -> interarrival = 14, jitter = 0
--------------------------------------------------------------------
last received 3
packet last sent 3
Data packet 4 was received
Packet 4 received Deadline: 1800, now: 510
Line 1 -> interarrival = 14, jitter = 0
--------------------------------------------------------------------
last received 4
packet last sent 4
Data packet 5 was received
Packet 5 received Deadline: 1800, now: 524
Line 1 -> interarrival = 14, jitter = 0
--------------------------------------------------------------------
last received 5
packet last sent 5
Data packet 6 was received
Packet 6 received Deadline: 1800, now: 538
Line 1 -> interarrival = 14, jitter = 0
--------------------------------------------------------------------
last received 6
packet last sent 6
Probe packet 7
Packet 7 received Deadline: 1800, now: 552
Line 1 -> interarrival = 14, jitter = 0
--------------------------------------------------------------------
last received 7
packet last sent 7
Probe 2 - packet 8
Packet 8 received Deadline: 1800, now: 552
measured delay for line 1 --> 0:134523246
New rate line 1: 9
period 100
--------------------------------------------------------------------
last received 8
packet last sent 8
Data packet 9 was received
Packet 9 received Deadline: 1800, now: 580
130
Line 1 -> interarrival = 28, jitter = 0
--------------------------------------------------------------------
last received 9
packet last sent 9
Data packet 10 was received
Packet 10 received Deadline: 1800, now: 589
received last element of frame
****---Enviando (11774) pro mpeg_play ***frame 2 (11774 bytes) received at time 589, deadline 1800
Line 1 -> interarrival = 9, jitter = 0
--------------------------------------------------------------------
last received 10
packet last sent 10
Data packet 11 was received
Packet 11 received Deadline: 2400, now: 598
Line 1 -> interarrival = 9, jitter = 0
--------------------------------------------------------------------
last received 11
packet last sent 11
Data packet 12 was received
Packet 12 received Deadline: 2400, now: 607
Line 1 -> interarrival = 9, jitter = 0
--------------------------------------------------------------------
last received 12
packet last sent 12
Probe packet 13
Packet 13 received Deadline: 2400, now: 616
Line 1 -> interarrival = 9, jitter = 0
--------------------------------------------------------------------
last received 13
packet last sent 13
Probe 2 - packet 14
Packet 14 received Deadline: 2400, now: 616
measured delay for line 1 --> 0:134523246
New rate line 1: 6
period 100
--------------------------------------------------------------------
last received 14
packet last sent 14
Data packet 15 was received
Packet 15 received Deadline: 2400, now: 634
received last element of frame
****---Enviando (6265) pro mpeg_play ***frame 3 (6265 bytes) received at time 634, deadline 2400
Line 1 -> interarrival = 18, jitter = 0
--------------------------------------------------------------------
last received 15
packet last sent 15
Data packet 16 was received
Packet 16 received Deadline: 3000, now: 640
received last element of frame
****---Enviando (757) pro mpeg_play ***frame 4 (757 bytes) received at time 640, deadline 3000
Line 1 -> interarrival = 6, jitter = 0
--------------------------------------------------------------------
131
last received 16
packet last sent 16
Data packet 17 was received
Packet 17 received Deadline: 3600, now: 646
received last element of frame
****---Enviando (823) pro mpeg_play ***frame 5 (823 bytes) received at time 646, deadline 3600
Line 1 -> interarrival = 6, jitter = 0
--------------------------------------------------------------------
last received 17
packet last sent 17
Data packet 18 was received
Packet 18 received Deadline: 4200, now: 652
received last element of frame
****---Enviando (665) pro mpeg_play ***frame 6 (665 bytes) received at time 652, deadline 4200
Line 1 -> interarrival = 6, jitter = 0
--------------------------------------------------------------------
last received 18
packet last sent 18
Probe packet 19
Packet 19 received Deadline: 4800, now: 658
Line 1 -> interarrival = 6, jitter = 0
--------------------------------------------------------------------
last received 19
packet last sent 19
Probe 2 - packet 20
Packet 20 received Deadline: 4800, now: 658
measured delay for line 1 --> 0:134523246
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 20
packet last sent 20
Data packet 21 was received
Packet 21 received Deadline: 4800, now: 670
Line 1 -> interarrival = 12, jitter = 0
--------------------------------------------------------------------
last received 21
packet last sent 21
Data packet 22 was received
Packet 22 received Deadline: 4800, now: 675
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 22
packet last sent 22
Data packet 23 was received
Packet 23 received Deadline: 4800, now: 680
received last element of frame
****---Enviando (6312) pro mpeg_play ***frame 7 (6312 bytes) received at time 680, deadline 4800
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 23
packet last sent 23
132
Data packet 24 was received
Packet 24 received Deadline: 5400, now: 685
received last element of frame
****---Enviando (914) pro mpeg_play ***frame 8 (914 bytes) received at time 685, deadline 5400
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 24
packet last sent 24
Probe packet 25
Packet 25 received Deadline: 6000, now: 690
received last element of frame
****---Enviando (893) pro mpeg_play ***frame 9 (893 bytes) received at time 690, deadline 6000
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 25
packet last sent 25
Probe 2 - packet 26
Packet 26 received Deadline: 6600, now: 690
received last element of frame
****---Enviando (878) pro mpeg_play ***frame 10 (878 bytes) received at time 690, deadline 6600
measured delay for line 1 --> 0: 2
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 26
packet last sent 26
ack probe
Line 1 -> interarrival = 25, jitter = 0
--------------------------------------------------------------------
last received 26
packet last sent 26
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 26
packet last sent 26
Data packet 27 was received
Packet 27 received Deadline: 7200, now: 725
received last element of frame
****---Enviando (692) pro mpeg_play ***frame 11 (692 bytes) received at time 725, deadline 7200
Line 1 -> interarrival = 10, jitter = -25
--------------------------------------------------------------------
last received 27
packet last sent 27
Data packet 28 was received
Packet 28 received Deadline: 7800, now: 730
received last element of frame
133
****---Enviando (3) pro mpeg_play ***frame 12 (3 bytes) received at time 730, deadline 7800
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe
Line 1 -> interarrival = 85, jitter = -5
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe
Line 1 -> interarrival = 100, jitter = -90
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe
Line 1 -> interarrival = 100, jitter = -190
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe
Line 1 -> interarrival = 100, jitter = -290
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe
Line 1 -> interarrival = 100, jitter = -390
--------------------------------------------------------------------
134
last received 28
packet last sent 28
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe
Line 1 -> interarrival = 100, jitter = -490
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe
Line 1 -> interarrival = 100, jitter = -590
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe
Line 1 -> interarrival = 100, jitter = -690
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe
Line 1 -> interarrival = 100, jitter = -790
--------------------------------------------------------------------
last received 28
packet last sent 28
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 28
135
packet last sent 28
Data packet 29 was received
Packet 29 received Deadline: 8400, now: 1645
received last element of frame
****---Enviando (7) pro mpeg_play ***frame 13 (7 bytes) received at time 1645, deadline 8400
Line 1 -> interarrival = 30, jitter = -885
--------------------------------------------------------------------
last received 29
packet last sent 29
Data packet 30 was received
Packet 30 received Deadline: 9000, now: 1650
received last element of frame
****---Enviando (40) pro mpeg_play ***frame 14 (40 bytes) received at time 1650, deadline 9000
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 30
packet last sent 30
Data packet 31 was received
Packet 31 received Deadline: 9600, now: 1675
Line 1 -> interarrival = 25, jitter = 0
--------------------------------------------------------------------
last received 31
packet last sent 31
Data packet 32 was received
Packet 32 received Deadline: 9600, now: 1680
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 32
packet last sent 32
Data packet 33 was received
Packet 33 received Deadline: 9600, now: 1685
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 33
packet last sent 33
Data packet 34 was received
Packet 34 received Deadline: 9600, now: 1690
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 34
packet last sent 34
Data packet 35 was received
Packet 35 received Deadline: 9600, now: 1695
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 35
packet last sent 35
Data packet 36 was received
Packet 36 received Deadline: 9600, now: 1700
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 36
packet last sent 36
136
Data packet 37 was received
Packet 37 received Deadline: 9600, now: 1705
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 37
packet last sent 37
Data packet 38 was received
Packet 38 received Deadline: 9600, now: 1710
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 38
packet last sent 38
Probe packet 39
Packet 39 received Deadline: 9600, now: 1715
received last element of frame
****---Enviando (11774) pro mpeg_play ***frame 15 (11774 bytes) received at time 1715, deadline 9600
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 39
packet last sent 39
Probe 2 - packet 40
Packet 40 received Deadline: 10200, now: 1715
measured delay for line 1 --> 0:134523246
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 40
packet last sent 40
Data packet 41 was received
Packet 41 received Deadline: 10200, now: 1725
Line 1 -> interarrival = 10, jitter = 0
--------------------------------------------------------------------
last received 41
packet last sent 41
Data packet 42 was received
Packet 42 received Deadline: 10200, now: 1730
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 42
packet last sent 42
Data packet 43 was received
Packet 43 received Deadline: 10200, now: 1735
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 43
packet last sent 43
Probe packet 44
Packet 44 received Deadline: 10200, now: 1740
received last element of frame
****---Enviando (6265) pro mpeg_play ***frame 16 (6265 bytes) received at time 1740, deadline 10200
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 44
packet last sent 44
137
Probe 2 - packet 45
Packet 45 received Deadline: 10800, now: 1740
received last element of frame
****---Enviando (757) pro mpeg_play ***frame 17 (757 bytes) received at time 1740, deadline 10800
measured delay for line 1 --> 0: 2
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 45
packet last sent 45
Probe packet 46
Packet 46 received Deadline: 11400, now: 1765
received last element of frame
****---Enviando (823) pro mpeg_play ***frame 18 (823 bytes) received at time 1765, deadline 11400
Line 1 -> interarrival = 25, jitter = 0
--------------------------------------------------------------------
last received 46
packet last sent 46
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 46
packet last sent 46
Data packet 47 was received
Packet 47 received Deadline: 12000, now: 1795
received last element of frame
****---Enviando (665) pro mpeg_play ***frame 19 (665 bytes) received at time 1795, deadline 12000
Line 1 -> interarrival = 30, jitter = 0
--------------------------------------------------------------------
last received 47
packet last sent 47
ack probe
Line 1 -> interarrival = 20, jitter = -30
--------------------------------------------------------------------
last received 47
packet last sent 47
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 47
packet last sent 47
Data packet 48 was received
Packet 48 received Deadline: 12600, now: 1825
Line 1 -> interarrival = 10, jitter = -20
--------------------------------------------------------------------
last received 48
packet last sent 48
Data packet 49 was received
138
Packet 49 received Deadline: 12600, now: 1830
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 49
packet last sent 49
Data packet 50 was received
Packet 50 received Deadline: 12600, now: 1835
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 50
packet last sent 50
Data packet 51 was received
Packet 51 received Deadline: 12600, now: 1840
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 51
packet last sent 51
Data packet 52 was received
Packet 52 received Deadline: 12600, now: 1845
received last element of frame
****---Enviando (6312) pro mpeg_play ***frame 20 (6312 bytes) received at time 1845, deadline 12600
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 52
packet last sent 52
Data packet 53 was received
Packet 53 received Deadline: 13200, now: 1855
received last element of frame
****---Enviando (914) pro mpeg_play ***frame 21 (914 bytes) received at time 1855, deadline 13200
Line 1 -> interarrival = 10, jitter = 0
--------------------------------------------------------------------
last received 53
packet last sent 53
Data packet 54 was received
Packet 54 received Deadline: 13800, now: 1885
received last element of frame
****---Enviando (893) pro mpeg_play ***frame 22 (893 bytes) received at time 1885, deadline 13800
Line 1 -> interarrival = 30, jitter = 0
--------------------------------------------------------------------
last received 54
packet last sent 54
Probe packet 55
Packet 55 received Deadline: 14400, now: 1915
received last element of frame
****---Enviando (878) pro mpeg_play ***frame 23 (878 bytes) received at time 1915, deadline 14400
Line 1 -> interarrival = 30, jitter = 0
--------------------------------------------------------------------
last received 55
packet last sent 55
ack probe 2
measured delay for line 1 --> 0:134522924
139
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 55
packet last sent 55
Data packet 56 was received
Packet 56 received Deadline: 15000, now: 1945
received last element of frame
****---Enviando (692) pro mpeg_play ***frame 24 (692 bytes) received at time 1945, deadline 15000
Line 1 -> interarrival = 30, jitter = 0
--------------------------------------------------------------------
last received 56
packet last sent 56
Data packet 57 was received
Packet 57 received Deadline: 15600, now: 1950
received last element of frame
****---Enviando (3) pro mpeg_play ***frame 25 (3 bytes) received at time 1950, deadline 15600
Line 1 -> interarrival = 5, jitter = 0
--------------------------------------------------------------------
last received 57
packet last sent 57
ack probe
Line 1 -> interarrival = 15, jitter = -5
--------------------------------------------------------------------
last received 57
packet last sent 57
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 57
packet last sent 57
ack probe
Line 1 -> interarrival = 100, jitter = -20
--------------------------------------------------------------------
last received 57
packet last sent 57
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 57
packet last sent 57
ack probe
Line 1 -> interarrival = 100, jitter = -120
--------------------------------------------------------------------
last received 57
packet last sent 57
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
140
period 100
--------------------------------------------------------------------
last received 57
packet last sent 57
ack probe
Line 1 -> interarrival = 100, jitter = -220
--------------------------------------------------------------------
last received 57
packet last sent 57
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 57
packet last sent 57
ack probe
Line 1 -> interarrival = 100, jitter = -320
--------------------------------------------------------------------
last received 57
packet last sent 57
ack probe 2
measured delay for line 1 --> 0:134522924
New rate line 1: 5
period 100
--------------------------------------------------------------------
last received 57
packet last sent 57
ack probe
Line 1 -> interarrival = 100, jitter = -420
--------------------------------------------------------------------
last received 57
packet last sent 57
ack probe 2
measured delay for line 1 -->
A saída do Mpeg_play é a imagem do vídeo.
141
Bibliografia [1] HUGO, Vitor. Video digital. Disponível em: <http://www.geocities.com/hollywood/studio/1630/>.
[2] HALSALL, Fred. Multimedia Communications (Applications, Networks, Protocols and
Standards). Editora Addison – Wesley, 1a edição.
[3] WILSON WOO. MPEG Vídeo – informações sobre cabeçalhos de arquivos MPEG, disponível
em [email protected]. Página única. Acesso feito em janeiro de 2004.
[4] MARQUES, Hugo; CRISTOVÃO, João. Berkeley, Vídeo na Internet. [2001?].
Disponível em <http://amalia.img.lx.it.pt/~fp/st/ano2000_2001/trabalhos2000_2001/trabalho2>.
Acesso em janeiro de 2004.
[5] L. MAGALHÃES e R. KRAVETS. Mmtp - multimedia multiplexing transport protocol.
Disponível em: <http://mobius.cs.uiuc.edu/publications.htm>.
[6] CECILIO, E. L., RODRIGUES, R. F. Video sob demanda. 1996. Relatório Técnico TM10 –
Pontifícia Universidade Católica do Rio de Janeiro.
[7] LITTLE, T. D. C., VENKATESH, D. Prospects for Interactive Video-on-Demand. IEEE
Multimedia, v. 1, n. 3, 1994.
[8] SAYWOOD, K. Introduction to Data Compression. Morgan Kaufmann, 1996.
[9] DIGITAL Audio Visual Council, DAVIC 1.4 Specifications. [on-line] Disponível:
<http://www.davic.org >. Acesso em dezembro de 2004.
[10] ROWE L. et al. MPEG Video in Software: Representation, Transmission and Playback, High
Speed Networking and Multimedia Computing. In: IS&T/SPIE Symposium on Eletrical Imaging
Science and Technology, San Jose, CA, 1994. Anais…, San Jose, CA, 1994.
[11] CYCLADES BRASIL. Guia Internet de conectividade. 6. ed. São Paulo: Editora SENAC, 2000.
142
[12] REGIS, Eduardo J. Protótipo de software para distribuição de arquivos recebidos por e-mail
via Internet. Blumenau, 2000. 86 f. Trabalho de Graduação (Bacharelado em Ciências da
Computação) – Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau.
[13] GRALLA, Preston. Como funciona a Internet. São Paulo: Quark Editora, 1996.
[14] COMMER, Douglas E. Redes de computadores e Internet. 2. ed. Porto Alegre: Bookman, 2001.
[15] PÉRICAS, Francisco A.. Redes de computadores: conceitos e arquiteturas. Blumenau.
Disponível em: <http://www.inf.furb.br/~pericas>.
[16] TANENBAUM, Andrew S. Redes de computadores. Rio de Janeiro: Campus, 1996.
[17] CARVALHO, Teresa C. Melo de Brito. Arquitetura de redes de computadores OSI e TCP/IP.
São Paulo: Makron Books, 1994.
[18] Site: MPEG - Moving Picture Experts Group: <http://www.mpeg.org.>. Acesso em fevereiro de
2004.
[19] T. SIKORA, “MPEG-1 and MPEG-2 digital video coding standards.” Site: http://wwwam.hhi.de/mpeg-video/papers/sikora/mpeg1_2/mpeg1_2.htm, Acesso feito em dezembro de 2003.
[20] “Berkley MPEG tools”, site: < http://bmrc.berkeley.edu/frame/research/mpeg/>. Acesso feito em
fevereiro de 2004.
[21]ROSS, Keith W. e KUROSE, James F. Computer Neworking: a top-down
approach featuring the Internet. Boston: Addison Wesley, Inc., 2001.
[22] MONTEIRO, Jânio; NUNES, Mário. Streaming Protocols, Olympic Project, 13/02/2002
143
[23] FAFALI,V., PATRIKAKIS,Ch e MINOGIANNIS, N. Commercial Video Streaming Servers,
Rate Control and Stream Switching Techniques, Olympic Project, 11/07/2003
[24] GURSES, Eren e AKAR, Gozde Bozdagt. Selective Frame Discarding for video streaming in
TCP/IP Networks.
[25] LIU, Chunlei. Multimedia Over IP: RSVP, RTP, RTCP, RTSP. Ohio, 2000.
Site: <http://www.cis.ohio-state.edu/~jain/cis788-97/ip_multimedia/index.htm>. Acesso em: out. 2003.
[26] RealNetworks, inc. Using RTSP with Firewalls, Proxies, and Other Intermediary Network
Devices, Version 2.0, 1998.
[27] HELLOSOFT, Real Time Protocol (RTP), The protocol for real-time multimedia services.
[28] Site: Apple. Disponível em <www.apple.com/quicktime/> .
[29] Site: RealNetworks. Disponível em <www.realone.real.com/>.
[30] Site: Microsoft. Disponível em <www.microsoft.com/windows/windowsmedia/>.
[31] ANDREWS, Christopher. Revamping MMTP. Disponível em:
<http://mobius.cs.uiuc.edu/publications.htm>.
[32] STEVENS, W.Richard. Unix Network Programming: Interprocess Communications with
Advanced Programming in the UNIX Environment. Editora: Prentice Hall PTR.
[33] D. D. Clark, M. Lambert, and L. Zhang, NETBLT: A High Throughput Transport Protocol.,,
1988.
[34] D. D. Clark and D. L. Tennenhouse, Architectural Considerations for a New Generation of
Protocols.
144
[35] E. D. Jensen, C. D. Locke, and H. Tokuda, A Time-Driven Scheduling Model for Real-Time
Operating Systems. in IEEE Real-Time Systems Symposium, 1985.
[36] S. Keshav, A Control-Theoretic Approach to Flow Control. presented at Proceedings of the
SIGCOMM '92 Symposium, 1992.
[37] Site: Sun Systens. Disponível em: <www.java.sun.com>. Acesso: março de 2004.