Distribuição de Vídeo ao Vivo em Multiponto
sobre redes IP Heterogéneas
Jânio M. E. F. Monteiro1,2, Mário Serafim Nunes1,3
(1) INESC, Lisboa (2) EST/UAlg, Faro
(3) Instituto Superior Técnico, Lisboa
Resumo
Quando se pretende fazer a transmissão de acontecimentos ao vivo sobre redes IP para milhares de receptores na Internet, os conceitos base a ter em conta são escalabilidade e heterogeneidade. A escalabilidade aponta para soluções que utilizem protocolos de routing IP Multicast, no entanto, a pouca utilização do IP Multicast ao nível das redes de acesso faz com que o Unicast continue a ser uma das soluções a ter também em conta. Em termos de Qualidade de Serviço (QoS), o modelo
Integrated Services (IntServ) definiu desde o início o suporte de IP Multicast, mas como é sabido
este modelo apresenta problemas de escalabilidade que o impossibilitam de ser aplicado ao núcleo da rede. Em termos de escalabilidade, o mesmo não acontece com o modelo Differentiated Services (DiffServ), no entanto o funcionamento do IP Multicast neste modelo está ainda em fase de definição pelo IETF. Neste âmbito, torna-se claro que o conceito de heterogeneidade abrange não só os terminais receptores de sequências de vídeo, mas também a própria rede em si, sendo necessário encontrar uma arquitectura que vá ao encontro de todos estes requisitos e soluções. A heterogeneidade em termos dos receptores diz-nos que cada receptor deverá receber uma sequência vídeo que seja função da sua própria capacidade de processamento e do percurso que o liga à fonte, independentemente da capacidade de outros receptores. O presente trabalho pretende analisar as soluções já definidas para a distribuição de vídeo ponto-multiponto, enunciando os problemas relacionados com cada uma delas e procurando uma solução que consiga abarcar a maioria dos requisitos que são colocados. A solução aqui considerada procura utilizar apenas protocolos normalizados pelo IETF para a distribuição de vídeo, procurando também analisar e quantificar o descarte selectivo de pacotes MPEG-1 e MPEG-2 vídeo como parte da solução para a heterogeneidade em ambientes que possibilitem QoS.
Palavras chave: Distribuição de Vídeo, IP Multicast, QoS, MPEG , Redes de Acesso.
1.
Introdução
A Internet, como meio de distribuição ao vivo de vários tipos de média, tem visto um grande crescimento nos últimos anos. Actualmente, acontecimentos ao vivo como concertos e provas desportivas transmitidas em directo na Internet, levam muitas vezes a que milhares de utilizadores queiram aceder ao mesmo tempo a esse evento.
Para além desses acontecimentos esporádicos, prevê-se também um elevado crescimento de canais televisivos que procuram ir ao encontro de nichos de clientes que podem encontrar-se em qualquer ponto do planeta. Um exemplo pode já ser encontrado no canal financeiro Bloomberg [1] com transmissão em directo na Internet em várias línguas. No futuro, prevê-se que este crescimento venha a ser acelerado com a entrada da nova geração de terminais móveis assentes em IP e com o aumento da largura de banda das redes de acesso.
Apesar deste acentuado crescimento de tráfego de média, a maioria das soluções encontradas actualmente continuam a suportar-se em ligações Unicast cliente-servidor, apresentando por isso problemas de escalabilidade quando milhares de utilizadores pretendem aceder ao mesmo evento. Neste âmbito torna-se importante encontrar não só soluções que incluam o maior número possível de utilizadores, mas também que ao mesmo tempo suportem clientes com diferentes características em termos de redes de acesso e capacidade de processamento (heterogeneidade).
Entre os diversos tipos de média, aquele que pela sua natureza e características exige maiores requisitos à rede que o suporta, é o vídeo. Por isso, quando se pretendem servir milhares de clientes ao mesmo tempo torna-se também impossível a retransmissão de pacotes de vídeo perdidos, dado o seu elevado peso em termos de largura de banda.
Para resolver o problema da escalabilidade uma das soluções principais assenta na utilização de protocolos de routing IP Multicast. Neste âmbito várias soluções para a distribuição de vídeo têm sido apontadas, testadas e mesmo utilizadas no Backbone Multicast (MBone), algumas das quais implementando também métodos para a resolução do problema da heterogeneidade. No entanto, a lenta aceitação de protocolos de routing Multicast pelos Internet Service Providers (ISPs) tem levado a que o IP Multicast seja apontado como uma das soluções, mas não a solução para todos os problemas de escalabilidade na distribuição de vídeo.
Utilizando os protocolos e soluções que garantem Qualidade de Serviço (QoS), em caso de erros, perda, ou descarte intencional de pacotes, a rede deverá fazê-lo de forma selectiva, com o intuito de minimizar os danos daí resultantes. Para tal deverá diferenciar, dentro de cada sequência de vídeo, os dados mais relevantes dos menos, descartando assim os menos importantes em primeiro lugar.
Neste documento pretendemos essencialmente analisar e apontar soluções relativas à escalabilidade e heterogeneidade da distribuição multiponto de vídeo. Este documento reflecte um trabalho em curso, apresentando resultados já obtidos até este momento, inserindo-se no entanto num trabalho muito mais vasto. Assim pretende-se analisar as várias soluções propostas para o transporte de vídeo sobre IP, quantificando as soluções de descarte selectivo de tráfego de vídeo em MPEG-1 [2] e MPEG-2 [3], com vista à sua implementação efectiva numa arquitectura que inclua Qualidade de Serviço.
O presente estudo insere-se no contexto do projecto OLYMPIC - Olympics Multimedia
Personalised for the Internet Community, financiado pelo programa Information Society Technologies (IST) da Comissão Europeia. O Projecto OLYMPIC [4] visa definir, implementar e
integrar soluções inovadoras ao nível das redes de comunicações bem como técnicas de codificação multimédia, com vista à realização de um sistema descentralizado, capaz de capturar e codificar centenas de sequências áudio e vídeo, a partir de fontes de média ao vivo e distribuí-las através da Internet global. Do referido projecto fazem parte várias empresas e organizações ao nível europeu, cuja representação nacional se faz através do Instituto de Engenharia de Sistemas e Computadores – Inovação (INESC-INOV). Com início em Dezembro de 2001 e com a duração total de 30 meses, o sistema completo ao nível da tecnologia, arquitectura, módulos e dispositivos deverá estar disponível, com uma cobertura mundial através da Internet global antes da realização dos Jogos Olímpicos de Atenas, em 2004 na Grécia. Em termos de codificação e distribuição, pretende-se neste projecto suportar o MPEG-2 e o MPEG-4 [5].
2.
Protocolos utilizados na Distribuição de Vídeo
Para que a distribuição de vídeo possa ser uma realidade têm sido utilizados na Internet vários protocolos, alguns dos quais proprietários. A análise seguinte refere-se apenas aos protocolos normalizados, focando fundamentalmente os protocolos definidos pelo Internet Engineering Task
A arquitectura de protocolos apresentada na figura seguinte (Figura 1) permite o transporte de dados multimédia em IP Multicast e Unicast, a sinalização e descrição dessas mesmas sessões, bem como a monitorização da entrega dos mesmos dados.
Dados de Média ↓ Monitorização da Distribuição de Dados de Média ↓ Anúncio e Publicitar de uma Sessão ↓ Descrição e Controlo da Apresentação ↓ Descrição de Sessão e Hipertexto ↓ SDP Nível de Aplicação MPEG-x, H.263, etc SAP RTSP HTTP RTP RTCP UDP TCP Nível de Transporte IP Nível de Rede
Figura 1: Arquitectura de Protocolos IETF utilizados no transporte, sinalização e descrição de dados de média
Os protocolos Real Time Protocol (RTP) and Real Time Control Protocol (RTCP) [6] fornecem serviços extremo-a-extremo para dados que apresentem requisitos de tempo real, tais como áudio e vídeo. Esses serviços incluem a identificação do tipo de dados transportados, identificações de sequência e temporal, e monitorização da entrega dos mesmos. O protocolo RTP transporta os dados de média e o RTCP monitoriza e troca informação entre os participantes numa sessão sobre a qualidade de serviço de cada um dos média transportados. Para que diferentes codificações de média possam ser suportados, o protocolo RTP permite a especificação do formato de cada média. Assim, por exemplo o RFC3016 [7] define o formato do campo de dados para o transporte de dados Áudio/Visual MPEG-4.
O protocolo Session Description Protocol (SDP) [8] permite descrever uma determinada sessão multimédia, podendo ser utilizado pelos protocolos SAP, RTSP e pelo HTTP. O protocolo SDP descreve o nome da sessão, o propósito da mesma, a descrição dos intervalos de tempo em que a mesma se verifica, a descrição de cada um dos média bem como a informação necessária para a recepção desses média (endereços, portos, etc).
O protocolo Session Announcement Protocol (SAP) [9] é utilizado apenas em IP Multicast em conjunto com directórios de sessão (session directories) no sentido de publicitar sessões Multicast e difundir a informação necessária para que um determinado utilizador se possa ligar à mesma. Cada aplicação que publicite anúncios SAP envia periodicamente descrições de sessão (SDP) para um determinado porto e endereço Multicast, sendo ambos bem definidos. Um utilizador que queira por isso participar numa sessão Multicast apenas terá que aderir a esse grupo Multicast e esperar por um desses anúncios SAP.
Por fim, o protocolo Real Time Streaming Protocol (RTSP) [10] permite controlar uma sessão de distribuição Unicast ou Multicast de dados com características de tempo real, podendo ser utilizado quer para dados de média armazenados, como ao vivo. O RTSP estabelece e controla uma ou várias sequências de áudio e vídeo, mas não faz a entrega dos dados, funcionando como um controlo remoto enviando comandos como PLAY, PAUSE, RECORD, etc. O RTSP pode utilizar o UDP ou o TCP para enviar esses comandos.
Nesta arquitectura, o Hypertext Transport Protocol (HTTP) [11] pode ser também utilizado para a troca de dados multimédia, em Unicast apenas, dado que só pode ser transportado pelo TCP como pode ser visto na Figura 1. No entanto como consequência das desvantagens do TCP no transporte de dados de média, é fundamentalmente utilizado para a troca de informação SDP, iniciando assim sessões Unicast ou Multicast.
3.
Soluções para a distribuição de Vídeo em Multicast
Tal como definido em [15] numa distribuição de vídeo em Multicast cada receptor deveria receber uma sequência vídeo que seja função da sua própria capacidade de processamento e do percurso que o liga à fonte, independentemente da capacidade de outros receptores.
Para ir ao encontro deste requisito fundamental, existem três tipos de soluções possíveis aplicáveis ao controlo de ritmos em distribuições Multicast: controlo baseado no emissor (servidor), controlo baseado no receptor (cliente) e esquemas de controlo híbridos entre servidor e cliente.
De entre estes três tipos de soluções destacam-se o Single-Stream Video Multicast (Multicast de uma única sequência de vídeo), Replicated-Stream Video Multicast (Multicast de várias sequências de vídeo independentes em paralelo) e o Layered Video Multicast (Multicast de várias sequências interdependentes em paralelo com ordem crescente de qualidade). Todas estas soluções foram desenvolvidas para serem utilizadas numa arquitectura Best Effort Multicast, como é o caso do MBone.
O Single-Stream Video Multicast é a solução mais simples, na qual um servidor envia para todos os clientes na rede uma única sequência vídeo. Aos receptores cabe enviar relatórios RTCP indicando as suas perdas, permitindo assim ao servidor ajustar o seu ritmo em função das perdas verificadas. Esta solução no entanto torna-se inaceitável à mediada que os grupos Multicast se tornem maiores por dois motivos fundamentais: por um lado porque os relatórios RTCP dos clientes poderão provocar um congestionamento em torno do servidor conduzindo ao conceito de feedback implosion e apresentando por isso problemas de escalabilidade; por outro lado porque o servidor terá que optar entre ajustar o seu ritmo ao receptor menos capaz, ou não considerar clientes abaixo de uma determinado limite em termos de largura de banda.
O Replicated-Stream Video Multicast é uma extensão natural do Single-Stream Video Multicast que consiste em enviar várias sequências com diferentes qualidades, aplicadas em diferentes árvores
Multicast. Desta forma, cada utilizador poderá aderir ao grupo Multicast que melhor se ajuste à sua
largura de banda. No entanto, devemos ter em consideração que a largura de banda de cada receptor variará ao longo do tempo. Continuando a aceitar como possível que dentro de um determinado limite seja possível a um cliente informar o servidor sobre a qualidade da sua recepção, continua a colocar-se o problema da escalabilidade da anterior solução. Neste âmbito, em [15] foi proposto um protocolo denominado de Destination Set Grouping (DSG) que procura resolver o problema da escalabilidade face ao feedback implosion e definir processos para a mudança entre grupos
Multicast. No entanto, a maior desvantagem do Replicated-Stream Video Multicast, resulta do
transporte de informação redundante que inevitavelmente acontecerá entre routers Multicast, continuando ainda assim a ser uma solução com muitas vantagens em termos de poupança de largura de banda, quando comparada com as soluções Unicast.
Steve Deering propôs em 1993 [16] a utilização de uma transmissão de vídeo em camadas, em que cada camada seja transportada em diferentes árvores Multicast, permitindo assim que cada cliente possa ajustar a sua largura de banda através da adesão e abandono de sucessivas camadas. Desta forma, cada utilizador poderia aderir a uma camada base e a partir daí aderir a mais camadas superiores. A esta proposta seguiram-se vários protocolos dos quais destacamos Receiver Driven
ThinStreams [20], entre outros. As vantagens da transmissão de vídeo em camadas fazem dela uma boa solução em termos de largura de banda e as normas de compressão vídeo têm vindo cada vez mais a suportar esta possibilidade.
Apesar de todos os desenvolvimentos evidenciados no domínio da transmissão de vídeo em IP
Multicast, em termos práticos continuam a utilizar-se várias sequências com diferentes qualidades
aplicadas em diferentes árvores Multicast, com pouco ou nenhum controlo cliente servidor. Um exemplo disso são as próprias reuniões do IETF transmitidas no MBone. Para além disso, não está clara de que forma será feita a integração entre o transporte de vídeo entre ambientes IP Multicast e
Unicast e de que forma se poderá fazer a interligação de ambos em ambientes que permitam
Qualidade de Serviço.
Em termos de Qualidade de Serviço, o modelo de Serviços Integrados (IntServ) define o seu funcionamento em ambientes IP Multicast através do protocolo Resource Reservation Protocol (RSVP) [26][27]. No entanto, como é sabido este modelo apresenta problemas de escalabilidade que o impossibilitam de ser aplicado ao núcleo da rede, sendo ainda assim considerada uma possível solução para a periferia da rede.
Em termos de escalabilidade, o mesmo não acontece com o modelo de Serviços Diferenciados (DiffServ), no entanto o funcionamento do IP Multicast neste modelo está ainda em fase de definição pelo IETF como é demonstrado em [33].
4.
Solução em Análise
Como se pode verificar pelas análises anteriores, dificilmente se poderá considerar uma solução única que consiga resolver todas as heterogeneidades da rede, indo ao mesmo tempo ao encontro das exigências dos clientes.
Para além disso, o facto de muitas das actuais redes de acesso não disponibilizarem o IP Multicast, faz com que tenham que ser consideradas soluções em que ambas as formas de distribuição estejam disponíveis a clientes que o desejem.
Por estes motivos, a arquitectura definida para ir ao encontro destas exigências e características passa pelo desenvolvimento de elementos colocados no interior da rede, os quais serão responsáveis pela adequação entre ambientes Multicast e Unicast (habitualmente denominados de reflectores ou
recasters) com funcionalidades adicionais de gestão da Qualidade de Serviço. Esses elementos
(denominados de servidores intermédios) serão colocados numa estrutura hierárquica sendo responsáveis pela gestão da qualidade de recepção dos clientes a que estão ligados. Cada servidor intermédio terá que monitorar os relatórios RTCP recebidos da parte dos clientes, podendo assim definir qual a sequência de vídeo que o cliente recebe, utilizando para tal o protocolo RTSP, em função das perdas por ele indicadas. Dentro desta estrutura hierárquica, cada servidor intermédio será ele mesmo visto como um cliente para o servidor hierarquicamente superior.
Esta solução tem a vantagem de não exigir alterações às aplicações clientes, para além naturalmente de suportar os protocolos definidos no ponto 2.
Com o objectivo de minimizar as consequências das perdas de pacotes que se venham a verificar, é ainda necessário encontrar uma solução que garanta uma qualidade de recepção o mais elevada possível, que se encaixe bem nos modelos IntServ e/ou DiffServ, e que não exija uma capacidade de processamento elevado por parte dos routers ou servidores intermédios. Neste sentido o descarte de pacotes é uma das soluções mais simples de implementar [25], sendo no entanto necessário verificar a sua vantagem na arquitectura proposta e analisar de que forma se fará a marcação de pacotes contendo sequências de vídeo, por forma a maximizar a percepção de qualidade por parte de um cliente. O seguinte trabalho reflecte essa análise.
5.
Descarte Selectivo de Vídeo
A normas MPEG-1 [2] e MPEG-2 [3] vídeo permitem utilizar diversos tipos de escalabilidade. No entanto devido à complexidade associada à utilização de mecanismos que envolvam descodificação e codificação total ou parcial de sequências de vídeo em Multicast, a grande maioria das soluções apontadas mantêm a codificação na fonte, cabendo à rede gerir essa codificação, quer seja no caso do Replicated-Streaming quer em Layered Streaming. Neste âmbito, procuramos aqui analisar a escalabilidade temporal de sequências vídeo aplicando o descarte selectivo permitido pela utilização das soluções DiffServ e IntServ.
Uma sequência elementar (Elementary Streams- ES) de vídeo MPEG-1 e MPEG-2 é composta por um ou mais Group of Pictures (GOPs), que por sua vez são compostos por sequências de imagens (Pictures) I, P ou B.
A ordem de transmissão das imagens reflecte a ordem pela qual elas são descodificadas. A título de exemplo, apesar das imagens de um vídeo serem apresentadas numa sequência “I1 B1 B2 P1 B3 B4
P2 B5 B6 P3 B7 B8 P4 […]” elas são transmitidas numa sequência “I1 P1 B1 B2 P2 B3 B4 P3 B5 B6 P4
B7 B8 […]”. O descodificador necessitará por isso receber I1 e P1, antes de poder descodificar B1 e
B2. Para além disso, a descodificação de uma imagem P depende da correcta descodificação de uma
I ou P anteriormente recebida, o mesmo acontecendo com as Bs. Por outro lado, a perda de uma imagem B não afecta nenhuma das outras imagens vizinhas. Ou seja, se quisermos dar diferentes prioridades de descarte a imagens I, P ou B, devemos fazê-lo pela ordem:
I - Menor Prioridade de Descarte P - Média Prioridade de Descarte B - Maior Prioridade de Descarte
Em MPEG-1 e MPEG-2, cada imagem é por sua vez composta de vários “slices”. Considerando o empacotamento de dados MPEG-1 e MPEG-2 tal como definido pelo IETF no RFC2250 [34], cada
slice é considerado a unidade de transmissão e recuperação em caso de perda de dados. Este RFC
especifica que sequências elementares (ES) de vídeo MPEG-1 e 2 podem ser transportadas em RTP com um cabeçalho de média específico, no qual existe um campo denominado de picture type (P), com um tamanho de 3 bits. Este campo identifica o tipo de imagem transportada, ou mais propriamente o tipo de slice transportado (podendo ser I, P, B ou D). As imagens D, definidas para o MPEG-1 [2] vídeo, contêm informação de baixa frequência permitindo a pesquisa rápida e visível de conteúdos, não sendo no entanto alvo de análise no presente estudo. O RFC2250 determina ainda que o identificador de início de um slice deverá aparecer como primeiros dados de um pacote, ou seguir um número inteiro de slices.
Ao nível da rede, torna-se por isso possível fazer a marcação selectiva de slices I, P ou B de acordo com o campo de payload type do cabeçalho de dados do RTP.
6.
Resultados da Simulação
Com base nas precedências anteriormente enunciadas e com o intuito de comparar o descarte selectivo com o descarte aleatório de pacotes de vídeo, foram realizados dois processos de descarte, um selectivo e outro aleatório, simulados em MATLAB para sequências de vídeo MPEG-1 e MPEG-2.
O objectivo destas simulações foi, não só o de obter ficheiros de vídeo MPEG-1 e MPEG-2 que possam ser reproduzidos localmente possibilitando assim a verificação da efectiva melhoria ou não do descarte selectivo face ao descarte aleatório, mas também o de quantificar os dados perdidos e afectados.
Em cada um dos9 cenários simulados apresentados na figura seguinte (Figura 2) foi aplicada uma sequências elementar de vídeo MPEG-1 e outra MPEG-2.
Figura 2: Diagrama de blocos comparativo dos cenários simulados: Descarte Aleatório versus Descarte Selectivo
A mesma sequência MPEG foi transmitida de forma cíclica aumentando em cada ciclo o descarte de pacotes de vídeo, simulando assim uma carga crescente na rede. O módulo cliente guardou depois cada um dos ficheiros recebidos, em função do descarte aplicado, para posterior reprodução. Assim, a figura seguinte (Figura 3) apresenta de forma comparativa os resultados obtidos para uma perda de 35% de dados.
a) Descarte aleatório b) Descarte selectivo
Figura 3: Comparação entre o descarte aleatório e o descarte selectivo de 35% dos dados.
Como se pode verificar na figura Figura 3a, a perda de determinados slices I ou P compromete a descodificação de slices P ou B posteriores dentro das precedências definidas anteriormente.
Em contrapartida, e para a sequência apresentada na figura Figura 3b, 35% de dados descartados correspondem a uma grande percentagem dos slices B existentes no vídeo original, ou seja foram eliminadas praticamente todas as imagens B mantendo-se os slices I e P na totalidade. Em termos de ritmo de imagens por segundo, e tendo em conta a estrutura do GOP, isto corresponde a uma diminuição de 30 imagens por segundo para perto de 5/13 deste valor (11,5 imagens por segundo).
Servidor
MPEG1/2 Descarte Aleatório Cliente
Servidor MPEG1/2
Marcação e Descarte
Assim a sequência vídeo começa a perder total ou parcialmente imagens intermédias, mas sem afectar outras imagens que delas dependam. Ou seja as imagens I e P aparecem integralmente, mas a perda de slices de imagens B faz baixar o ritmo de imagens por segundo.
Em termos visuais a vantagem do descarte selectivo é clara, aumentando à medida que aumentamos a quantidade de pacotes perdidos. O descarte selectivo permite assim uma degradação gradual da qualidade de recepção em função do congestionamento verificado na rede.
A figura seguinte (Figura 4) apresenta de forma comparativa os resultados obtidos para uma perda de 60% de dados.
a) Descarte aleatório b) Descarte selectivo
Figura 4: Comparação entre o descarte aleatório e o descarte selectivo de 60% dos dados.
A eliminação completa de imagens B e P acontece para esta sequência quando se atingem aproximadamente os 80% de perdas. Em termos de ritmo de imagens por segundo obtemos 1/13 do valor inicial ou seja 2.3 imagens por segundo. Este ritmo de imagens por segundo é já bastante baixo e será por isso de evitar, sendo preferível utilizar outros métodos de escalabilidade.
Com o intuito de quantificar estes resultados, aplicou-se ao sistema uma função de quantificação de perdas efectivas (em bytes) e de quantificação de dados que, apesar de recebidos, não podem ser adequadamente descodificados pelas precedências enunciadas anteriormente. Ou seja, para além dos dados eliminados num congestionamento (apresentados a tracejado nas próximas figuras) contabilizam-se os dados que, não sendo eliminados, são afectados na sua descodificação (apresentados a traço contínuo) pela perda de slices I ou P que deveriam ter sido recebidos anteriormente.
A Figura 5 mostra os resultados obtidos para a sequência vídeo MPEG-2 quando se aplicam descartes aleatórios. Como se pode verificar, no descarte aleatório da sequência MPEG-2, a valores baixos de perdas (de 1 a 10%) correspondem valores entre 1 a 1,5 vezes superiores de dados recebidos mas afectados, que acrescem aos efectivamente perdidos. Estes valores variaram consoante a sequência aplicada (MPEG-1 ou MPEG-2) tendo obtido em termos práticos valores afectados até 2,5 vezes os efectivamente descartados.
Figura 5: Dados efectivamente eliminados (tracejado) versus dados afectados (traço contínuo) num Descarte Aleatório de slices MPEG2
Para a mesma sequência de vídeo MPEG-2 apresentado na Figura 5 aplicou-se o descarte selectivo de
slices I, P e B, obtendo os dados da figura seguinte (Figura 6).
Figura 6: Dados efectivamente eliminados (tracejado) versus dados afectados (traço contínuo) num Descarte Selectivo de slices MPEG2
Como se pode constatar pela Figura 6, a perda selectiva de pacotes contendo slices MPEG permite reduzir os danos de outros dados que apesar de recebidos não podem ser descodificados, ou que são descodificados de forma errada.
Aplicando o descarte selectivo, começam por ser eliminados os slices B (aproximadamente até aos 30% de perdas), seguidos dos slices P (aproximadamente até aos 70% de perdas) e finalmente só acima dos 70% começam a ser eliminados os slices I. Verifica-se no entanto, que entre aproximadamente os 30% de perdas e os 70% de perdas a curva de dados afectados separa-se da curva de dados efectivamente perdidos, ou seja existem dados que apesar de recebidos são afectados pela perda de pacotes anteriores.
Tal facto deve-se a que neste intervalo já só se encontram tramas P e I, numa sequência semelhante a “I1 P1 P2 P3 P4”. Como seria de esperar, a perda de um slice P1 terá inevitavelmente que afectar a
descodificação de P2, P3 e P4. O mesmo se passa entre P2 em relação a P3 e P4, e finalmente entre P3
e P4. A única solução seria dar prioridades crescentes de descarte a “P1 P2 P3 P4”, no entanto ao
nível da marcação em rede esta tarefa torna-se bem mais complicada. De qualquer forma poderá vir a ser feita por aplicações especializadas.
O mesmo algoritmo foi aplicado a uma sequência MPEG-1. A figura seguinte (Figura 7) mostra os resultados para o descarte selectivo.
Figura 7: Dados efectivamente eliminados (tracejado) versus dados afectados (traço contínuo) num Descarte Selectivo de slices MPEG1
Para esta sequência MPEG-1 verifica-se o mesmo efeito verificado na Figura 6, mas agora aproximadamente entre os 40% e os 80%.
7.
Conclusões e Desenvolvimentos Futuros
Os dados recolhidos evidenciam que o descarte selectivo, apesar de ser preferível ao descarte aleatório de sequências vídeo, necessita de ser integrado numa solução mais completa. Ou seja,
terão de ser considerados outros mecanismos de ajuste de ritmo tais como os propostos para o MBone. De entre estes mecanismos o Replicated Stream Video Multicast aparece como o de mais provável implementação por não exigir grandes alterações a aplicações servidoras e clientes.
Apesar de só por si não ser uma solução completa, o descarte selectivo permite algum grau de degradação progressiva que, em conjunto com outros métodos, pode diminuir a percepção de perdas de pacotes.
Os resultados simulados foram já sumariamente testados numa arquitectura DiffServ mostrando a validade dos mesmos. No entanto até ao momento, ainda só foram atribuídos serviços de encaminhamento Expedited Forward (EF) [30] quer a tramas I, quer a tramas I e P, classificando o restante tráfego como Best Effort. Tendo em conta os carácter dinâmico do desenvolvimento do presente projecto, pretende-se explorar e quantificar estes dados através da atribuição de diferentes classes de prioridade e precedências de descarte Assured Forward (AF) [31].
No âmbito do projecto OLYMPIC está já também em desenvolvimento a marcação selectiva de sequências MPEG-4 ao nível dos Video Object Planes (VOP) I, P e B.
8.
Referências
[1] Bloomberg home page: http://www.bloomberg.com
[2] ISO/IEC International Standard 11172; "Coding of moving pictures and associated audio for digital storage media up to about 1,5 Mbits/s", November 1993.
[3] ISO/IEC International Standard 13818; "Generic coding of moving pictures and associated
audio information", November 1994.
[4] OLYMPIC Project home page: http://olympic.sema.es
[5] ISO/IEC International Standard 14496; “Information Technology – Coding of Audio-Visual Objects”, 2001.
[6] H. Schulzrinne, et al., "RTP: A Transport Protocol for Real-Time Applications", RFC1889, Internet Engineering Task Force, January 1996.
[7] Y. Kikuchi, et al., "RTP Payload Format for MPEG-4 Audio/Visual Streams," RFC3016, Internet Engineering Task Force, November 2000.
[8] M. Handley, and V. Jacobson, "SDP: Session Description Protocol", RFC2327, Internet Engineering Task Force, April 1999.
[9] M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol", RFC2974, Internet Engineering Task Force, October 2000.
[10] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC2326, Internet Engineering Task Force, April 1998.
[11] R. Fielding, J. Gettys, J. Mogul, H. Nielsen, T. Berners-Lee, "Hypertext transfer protocol - HTTP/1.1", RFC2068, Internet Engineering Task Force, January 1997.
[12] H. Schulzrinne, "RTP profile for Audio and Video Conferences with Minimal Control", RFC1890, Internet Engineering Task Force, January 1996.
[13] H. Schulzrinne, J. Rosenberg, "Internet Telephony: architecture and protocols - an IETF perspective", Computer Networks 31, 1999, pp. 237-255.
[14] X. Li, M. H. Ammar and S. Paul, “Video Multicast over the Internet,” IEEE Network, March/April 1999.
[15] S. Cheung, M. H. Ammar and X. Li, “On the use of destination set Grouping to improve Fairness in Multicast Video Distribution”, Proc. of IEEE INFOCOM ’96 (San Francisco, CA), March 1996, pp 553-560.
[16] S. E. Deering, “Internet Multicast Routing: state of the Art and Open Research Issues,”
Multimedia Integrated Conferencing for Europe (MICE) Seminar at the Swedish Institute of
Computer Science. October 1993.
[17] S. McCanne, V. Jacobson and M. Vetterli, “Receiver-driven Layered Multicast,” Proceedings
of ACM SIGCOMM ’96, Stanford, CA.
[18] X. Li et al., “Layered Video Multicast with Retransmission (LVMR): Evaluation of Error Control Schemes”, Proc. of NOSDAV ‘97 (St. Luis, MI), May 1997.
[19] X. Li, S. Paul, and M. H. Ammar “Layered Video Multicast with Retransmission (LVMR): Evaluation of Hierarchical Rate Control”, Proc. of IEEE INFOCOM ‘98 (San Francisco, CA), March 1998.
[20] L. Wu, R. Sharma, and B. Smith, “Thin Streams: An Architecture for Multicast Layered Video,” Proc. of NOSDAV ‘97 (St. Luis, MI), May 1997.
[21] J.C. Bolot, T. Turletti, and I. Wakeman, “Scalable Feedback control for Multicast video distribution”, Proceedings of ACM Sigcomm, September 1994.
[22] R. Yavatkar, L. Manoj, “Optimistic strategies for large scale dissemination of multimedia information”, Proceedings of ACM Multimedia ’93, Anaheim, CA, August 1993.
[23] N. Shacham, “Multipoint communications by Hierarchically Encoded Data”, Proc. of
INFOCOM 92, March 1992, pp. 2107-2114.
[24] G. Conklin, et al.,“Video Coding for Streaming Media Delivery on the Internet”, IEEE Transactions on Circuits and Systems for Video Technology, March 2001.
[25] N. Yadon, et al., “Filters: QoS support Mechanisms for Multipeer Communications,” IEEE Journal of Selected Areas in Communications, 3rd Quarter 1996.
[26] R. Braden, et al., "Resource reservation protocol (RSVP) -- Version 1 Functional Specification", RFC2205, Internet Engineering Task Force, September 1997.
[27] J. Wroclawski, "The use of RSVP with IETF Integrated Services," RFC2210, Internet Engineering Task Force, September 1997.
[28] S. Blake, et al., "An Architecture for the Differentiated Services," RFC2475, Internet Engineering Task Force, December 1998.
[29] K. Nichols, et al, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474, Internet Engineering Task Force, December 1998.
[30] V. Jacobson, et al., "An Expedited Forwarding PHB Group," RFC2598, Internet Engineering Task Force, June 1999.
[31] J. Heinanen et al., "Assured Forwarding PHB Group," RFC2597, Internet Engineering Task Force, June 1999.
[32] K. Almeroth "The evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment," IEEE Network, Jan./Feb. 2000.
[33] R. Bless and K. Wehrle "IP Multicast in Differentiated Services Networks", work-in-progress, Internet-Draft "draft-bless-diffserv-Multicast-03.txt", Internet Engineering Task Force, March 2002.
[34] D. Hoffmann, G. Fernando, V. Goyal, M. Civanlar, “RTP Payload Format for
