e Protocolos de Streaming Aplicações Multimídia Multimídia Aplicações jitter Variação de retardo Efeito do jitter

Transcrição

1 Departamento de Engenharia de Telecomunicações - UFF e Protocolos de Streaming Profa. Débora Christina Muchaluat Saade deborams@telecom.uff.br multimídia (mídia contínua) Sensíveis ao retardo e variação do retardo (jitter) Pacotes que sofrem retardos de centenas de ms (telefonia IP) até poucos segundos (recepção de mídia armazenada) são inúteis Tolerantes a perdas Perdas ocasionais causam pequenas perturbações na recepção de áudio e vídeo Essas características diferem das aplicações tradicionais (mídia discreta) 1 3 Variação de retardo Efeito do jitter jitter Classificação das aplicações multimídia: Transmissão de mídia contínua armazenada Transmissão de mídia contínua ao vivo Transmissão de mídia contínua interativa 4 5

2 com mídia contínua armazenada Conteúdo foi pré-gravado e armazenado em um servidor Clientes solicitam arquivos de aúdio e vídeo de servidores, recebem a informação pela rede e a apresentam Usuário pode controlar a operação similar a um VCR: pause, resume, fast forward, rewind, etc. Fluxo contínuo: Clientes reproduzem parte do conteúdo ao mesmo tempo em que recebem o restante pela rede Reprodução contínua: Assim que se inicia a reprodução da mídia, ela deve prosseguir de acordo com a temporização original da gravação Restrições ao atraso na entrega dos dados Retardo: Resposta considerada aceitável se o tempo a partir do pedido do cliente até o início da apresentação for de 1 a 10 segundos com mídia contínua transmitida ao vivo tempo-real unidirecional similar à difusão de rádio e TV convencional, mas a transferência de informação é feita pela Internet Se armazenar o fluxo no cliente, pode pausar e retroceder Muitos clientes recebem o mesmo conteúdo simultaneamente Distribuição eficiente precisa de comunicação multicast Retardo: Resposta considerada aceitável se o tempo a partir do pedido do cliente até o início da apresentação for de 1 a 10 segundos 6 7 Limitações da Internet Atual com mídia contínua interativa Tempo-real interativo Conferência de aúdio ou de vídeo Mais exigente nos requisitos de retardo e variação do retardo que o tempo-real unidirecional por causa da necessidade de interatividade em tempo-real Retardos: Aúdio: < 150 ms bom de 150 a 400 ms aceitável Arquitetura Internet fornece serviço de melhor esforço Não há garantias sobre o retardo ou sobre a variação do retardo Congestionamento na rede causa problema na Internet pública todos os pacotes recebem tratamento igual Pacotes contendo aúdio e vídeo interativo de tempo-real permanecem nas filas, como todos os outros. Projeto de aplicações multimídia seria mais fácil se houvesse várias classes de serviço Esforços vêm sendo desenvolvidos para prover serviços diferenciados com garantias de QoS qualidade de serviço. Modelos intserv e diffserv 8 9

3 Aproveitando ao máximo o melhor esforço Para reduzir o impacto do serviço de melhor esforço da Internet, nós podemos: Usar UDP para evitar o TCP e sua fase de partida lenta Armazenar o conteúdo no cliente e controlar a apresentação para remediar o jitter Acrescentar marcas de tempo nos pacotes para que o receptor saiba quando reproduzi-los. Adaptar o nível de compressão à taxa de transmissão disponível Nós podemos transmitir pacotes redundantes para atenuar os efeitos das perdas de pacotes. interativas em tempo-real Exemplo: Telefonia IP Telefonia Internet sobre melhor-esfor esforço Real-Time Protocol (RTP) Serviço de Melhor esforço Acarreta atraso de pacotes, perdas e variação de retardo (jitter) Exemplo de telefone Internet As aplicações de telefonia na Internet geram pacotes durante momentos de atividade da voz Rajadas de voz alternadas com períodos de silêncio cabeçalho RTP é acrescentado ao bloco; então bloco mais cabeçalho são encapsulados num pacote UDP e enviados alguns pacotes podem ser perdidos e o retardo de um pacote irá flutuar. Técnicas de FEC (forward error correction) e de compensação do jitter RTP especifica uma estrutura de pacotes que transportam dados de aúdio e vídeo: RFC pacote RTP oferece identificação do tipo de carga numeração da seqüência de pacotes marcas de tempo RTP roda nos sistemas terminais. os pacotes RTP são encapsulados em segmentos UDP Interoperabilidade: se duas aplicações de telefonia IP usam RTP, então elas podem ser capazes de trabalhar juntas 26 40

4 RTP roda em cima do UDP RTP: Exemplo RTP é um protocolo de aplicação Alguns autores o colocam como subcamada de transporte As bibliotecas do RTP fornecem uma interface que estende o UDP: número de portas, endereços IP identificação do tipo de carga numeração da seqüência de pacotes marcas de tempo camada de transporte Aplicação Enlace Física Considere enviar 64 kbps de voz codificada em PCM sobre RTP. A aplicação reúne dados codificados em blocos, por exemplo, a cada 20 ms = 160 bytes por bloco. O bloco de aúdio, junto com o cabeçalho RTP forma o pacote RTP, que é encapsulado num segmento UDP. O cabeçalho RTP indica o tipo de codificação de aúdio em cada pacote, os transmissores podem mudar a codificação durante a conferência. O cabeçalho RTP também contém os números de seqüência e marcas de tempo Tipo de Carga Número de Seqüência Cabeçalho alho RTP Marca de tempo Cabeçalho RTP 44 Identificador sincronismo fonte campos de miscelânias Tipo de Carga (7 bits): Usado para indicar o tipo de codificação que está sendo usado no momento. Se um transmissor muda o tipo de codificação durante uma conferência, o transmissor informa o receptor através deste campo de tipo de carga. Tipo de carga 0: PCM mu-law, 64 Kbps Tipo de carga 7, LPC, 2.4 Kbps Tipo de carga 9, G.722, Kbps Tipo de carga 14, MPEG1 áudio Tipo de carga 26, Motion JPEG Tipo de carga 31. H.261 Tipo de carga 32, MPEG1 vídeo Tipo de carga 33, MPEG2 vídeo Número de Seqüência (16 bits): O número de seqüência é incrementado de um a cada pacote RTP enviado; pode ser usado para detectar perdas de pacotes e ocultar os dados perdidos. Cabeçalho alho RTP 45 Campo de marca de tempo (32 bits). Reflete o instante de amostragem do primeiro byte no pacote de dados RTP. O receptor pode usar esta marca de tempo para remover o jitter do pacote e para obter o sincronismo de reprodução. A marca de tempo é derivada do relógio de amostragem no transmissor. Comoexemplo,para aúdioorelógiodemarcade tempoincrementade um a cada intervalo de amostragem (por exemplo, cada 125 microsseg para uma taxa de amostagem de 8 KHz); se a aplicação de aúdio gera blocos contendo 160 amostras codificadas, então a marca de tempo do RTP aumenta de 160 para cada pacote RTP quando a fonte está ativa. O relógio de marca de tempo continua a aumentar numa taxa constante mesmo quando a fonte está inativa. campo SSRC (identificador de sincronismo fonte) (32 bits). Identifica a fonte do fluxo RTP. Cada fluxo numa sessão RTP deve ter um SSRC distinto (atribuído aleatoriamente pela fonte). (serve para multiplexar vários fluxos de mídia em um único fluxo UDP)

5 Real-Time Control Protocol (RTCP) RTCP - Continuação Trabalha em conjunto com o RTP. Cada participante de uma sessão RTP transmite periodicamente pacotes de controle RTCP para todos os outros participantes. Cada pacote RTCP contém relatórios do transmissor e/ou do receptor que são úteis para a aplicação. As estatísticas incluem o número de pacotes enviados, número de pacotes perdidos, variação de retardo entre chegadas, etc. Esta informação de realimentação para a aplicação pode ser usada para controle do desempenho e para fins de diagnóstico. O transmissor pode mudar suas transmissões com base nestas informações de realimentação. - Para uma sessão RTP existe tipicamente um único endereço multicast, todos os pacotes RTP e RTCP pertencentes à sessão usam este endereço multicast. - Os pacotes RTP e RTCP são distintos uns dos outros pelo uso de números de portas diferentes. - Para limitar o tráfego, cada participante reduz seu tráfego RTCP quando o número de participantes da conferência aumenta Pacotes RTCP RTP e QoS Pacotes de relatório do receptor: fração de pacotes perdidos, último número de seqüência, variância média do atraso entre chegadas. Pacotesderelatóriodo transmissor: SSRC do fluxo RTP, marca de tempo e o tempo corrente real do pacote mais recente, o número de pacotes enviados e o número de bytes enviados. Pacotes de descrição da fonte: endereço de do transmissor, o nome do transmissor, o SSRC do fluxo RTP associado. Esses pacotes fornecem um mapeamento entre o SSRC e o nome do usuário ou do host. RTP não fornece nenhum mecanismo para assegurar a entrega dos pacotes e dados no tempo correto, nem fornece outras garantias de qualidade de serviço. O encapsulamento RTP é visto apenas nos sistemas finais -- ele não é percebido pelos roteadores intermediários. Roteadores fornecem o serviço de melhor-esforço tradicional da Internet. Eles não fazem nenhum esforço especial para assegurar que os pacotes RTP cheguem no destino no momento correto. A fim de fornecer QoS para uma aplicação, a Internet deve prover mecanismos especiais: Intserv Diffserv 48 52