Distribuição de Vídeo ao Vivo em Multiponto sobre redes IP Heterogéneas

Transcrição

1 Distribuição de Vídeo ao Vivo em Multiponto sobre redes IP Heterogéneas Jânio M. E. F. Monteiro 1,2, Mário Serafim Nunes 1,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.

2 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 Force (IETF).

3 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 MPEG-x, H.263, etc 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 SDP Descrição de Sessão e Hipertexto SAP RTSP HTTP Nível de Aplicação 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.

4 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 Layered Multicast (RLM) [17], Layered Video Multicast with Retransmission (LVMR)[18][19],

5 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.

6 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 I 1 B 1 B 2 P 1 B 3 B 4 P 2 B 5 B 6 P 3 B 7 B 8 P 4 [ ] elas são transmitidas numa sequência I 1 P 1 B 1 B 2 P 2 B 3 B 4 P 3 B 5 B 6 P 4 B 7 B 8 [ ]. O descodificador necessitará por isso receber I 1 e P 1, antes de poder descodificar B 1 e B 2. 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.

7 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. Servidor MPEG1/2 Descarte Aleatório Cliente Servidor MPEG1/2 Marcação e Descarte Selectivo Cliente 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).

8 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.

9 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

10 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 I 1 P 1 P 2 P 3 P 4. Como seria de esperar, a perda de um slice P1 terá inevitavelmente que afectar a descodificação de P 2, P 3 e P 4. O mesmo se passa entre P2 em relação a P 3 e P 4, e finalmente entre P 3 e P 4. A única solução seria dar prioridades crescentes de descarte a P 1 P 2 P 3 P 4, 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,

11 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: [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 [3] ISO/IEC International Standard 13818; "Generic coding of moving pictures and associated audio information", November [4] OLYMPIC Project home page: [5] ISO/IEC International Standard 14496; Information Technology Coding of Audio-Visual Objects, [6] H. Schulzrinne, et al., "RTP: A Transport Protocol for Real-Time Applications", RFC1889, Internet Engineering Task Force, January [7] Y. Kikuchi, et al., "RTP Payload Format for MPEG-4 Audio/Visual Streams," RFC3016, Internet Engineering Task Force, November [8] M. Handley, and V. Jacobson, "SDP: Session Description Protocol", RFC2327, Internet Engineering Task Force, April [9] M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol", RFC2974, Internet Engineering Task Force, October [10] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC2326, Internet Engineering Task Force, April [11] R. Fielding, J. Gettys, J. Mogul, H. Nielsen, T. Berners-Lee, "Hypertext transfer protocol - HTTP/1.1", RFC2068, Internet Engineering Task Force, January [12] H. Schulzrinne, "RTP profile for Audio and Video Conferences with Minimal Control", RFC1890, Internet Engineering Task Force, January [13] H. Schulzrinne, J. Rosenberg, "Internet Telephony: architecture and protocols - an IETF perspective", Computer Networks 31, 1999, pp [14] X. Li, M. H. Ammar and S. Paul, Video Multicast over the Internet, IEEE Network, March/April [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

12 [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 [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 [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 [20] L. Wu, R. Sharma, and B. Smith, Thin Streams: An Architecture for Multicast Layered Video, Proc. of NOSDAV 97 (St. Luis, MI), May [21] J.C. Bolot, T. Turletti, and I. Wakeman, Scalable Feedback control for Multicast video distribution, Proceedings of ACM Sigcomm, September [22] R. Yavatkar, L. Manoj, Optimistic strategies for large scale dissemination of multimedia information, Proceedings of ACM Multimedia 93, Anaheim, CA, August [23] N. Shacham, Multipoint communications by Hierarchically Encoded Data, Proc. of INFOCOM 92, March 1992, pp [24] G. Conklin, et al., Video Coding for Streaming Media Delivery on the Internet, IEEE Transactions on Circuits and Systems for Video Technology, March [25] N. Yadon, et al., Filters: QoS support Mechanisms for Multipeer Communications, IEEE Journal of Selected Areas in Communications, 3 rd Quarter [26] R. Braden, et al., "Resource reservation protocol (RSVP) -- Version 1 Functional Specification", RFC2205, Internet Engineering Task Force, September [27] J. Wroclawski, "The use of RSVP with IETF Integrated Services," RFC2210, Internet Engineering Task Force, September [28] S. Blake, et al., "An Architecture for the Differentiated Services," RFC2475, Internet Engineering Task Force, December [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 [30] V. Jacobson, et al., "An Expedited Forwarding PHB Group," RFC2598, Internet Engineering Task Force, June [31] J. Heinanen et al., "Assured Forwarding PHB Group," RFC2597, Internet Engineering Task Force, June [32] K. Almeroth "The evolution of Multicast: From the MBone to Interdomain Multicast to Internet2 Deployment," IEEE Network, Jan./Feb [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 [34] D. Hoffmann, G. Fernando, V. Goyal, M. Civanlar, RTP Payload Format for MPEG1/MPEG2 Video, October 1996.