Transporte Multimídia em Redes Transporte Multimídia em Redes A transmissão multimídia requer que garantias diversas de Qualidade de Serviço (QoS) sejam estabelecidas e mantidas para que se atendam aos requisitos específicos das diferentes mídias As redes deve oferecer suporte a restrições diversas fim-a-fim, ou seja, em todo o caminho da origem até o destino Slide 102 Slide 103 Transmissão multimídia em tempo real O crescimento da Internet e das intranets motivou sua utilização como base para o transporte de fluxos de dados multimídia sobre redes sem garantias de QoS baseadas no IP O desenvolvimento das áreas de codificação de sinais e de novos protocolos de rede tornou a transmissão desse tipo de fluxo possível Categorias dos protocolos Sinalização Vários protocolos podem ser utilizados para as funções de alto nível de sinalização e controle de sessão (conversação) SDP(Session Description Protocol) para descrever sessões multimídia SAP (Session Announcement Protocol) para anunciar as sessões descritas SIP (Session Initiation Protocol) para o convite de usuários (humanos ou máquinas) para participarem de sessões multimídia Pode- se dizer que HTTP e URL são também exemplos de um tipo específico de sinalização Slide 104 Slide 105
Mais categorias dos protocolos Controle de sessão Define as mensagens e procedimentos para controlar a entrega de dados multimídia durante o estabelecimento de uma sessão RTSP (Real- Time Streaming Protocol) Permite a escolha de canais e mecanismos de entrega Seleção de um segmento de dados multimídia para exibição e controle de exibição ou propriedades de gravação similares às de um video- cassete Mais categorias de protocolo Transporte Tem relação íntima com a forma com que os tipos de carga multimídia são organizados e usados RTP (Real-Time Transport Protocol) é o exemplo-chave! Infra- estrutura de rede Protocolos multimídia dependem dos protocolos de transporte fundamentais, que são o UDP e o TCP por causa de várias funções como multiplexação, controle de erro e de fluxo PPP (Point-to-Point Protocol) define um método padronizado para o envio de datagramas por um link de comunicação como de telefonia e linhas ISDN e é fundamental para diversas aplicações de transmissão de dados em tempo real RSVP é importante para a entrega de dados multimídia na Internet Slide 106 Slide 107 RTP (Real-Time Transport Protocol) Foi desenvolvido para o transporte de vários tipos de dados em tempo real através de redes de pacotes Baseia-se em protocolos bem estabelecidos para roteamento, multiplexação e temporização Provê um arcabouço (framework) interessante para a transformação em pacotes de conteúdo multimídia. Exemplo: pacotes baseados em slices no MPEG RTP Identificação do tipo de carga Um número inteiro caracteriza o tipo de dados sendo transportado Alguns tipos bastante utilizados são reservados Outros tipos menos populares recebem dinamicamente valores como, por exemplo, na abertura de uma sessão Permite que dados específicos do tipo de informação sendo carregado sejam inclusos em seu cabeçalho Slide 108 Slide 109
RTP Seqüenciamento dos pacotes Cada pacote RTP que pertence a um mesmo fluxo contém um número de 16 bits que é incrementado a cada pacote enviado Número inicial aleatório para evitar ataques em possíveis esquemas de criptografia externos Detecção de pacotes perdidos Ordenamento dos pacotes RTP Selo de tempo Cada pacote RTP carrega um selo de tempo de 32 bits que reflete o instante de exibição do primeiro byte na porção de dados do pacote O selo de tempo, junto com informação fornecida pelos pacotes RTCP associados é usado para: Pareamento (matching) de relógio do codificador e do decodificador Sincronização de diversas fontes Medida de retardo médio variável (jitter) dos pacotes recebidos Slide 110 Slide 111 RTP Identificação da origem A origem de cada pacote RTP é identificada por um inteiro chamado SSRC (Syncronization Source) incluido no cabeçalho É de responsabilidade do transmissor garantir um número único quando mais de um receptor requer o mesmo número em sessões distintas RTP Qualidade da distribuição e temporização Em uma sessão RTP, cada transmissor e receptor manda relatórios periódicos para cada participante da sessão: Fração de pacotes RTP perdidos desde o último relatório Número cumulativo de pacotes perdidos desde o começo da recepção Jitter entre a chegada de pacotes Retardo desde o recebimento do último relatório do transmissor Slide 112 Slide 113
Pacotes de Voz Pacotes de Voz Em comparação com comutação por circuito: Uso mais eficiente da capacidade do canal de comunicação, especialmente em tráfego em rajada A voz aceita uma certa margem de perda, mas não tolera retardos fora da faixa de 100ms a 600ms A amostragem da voz precisa ser feita em intervalos pequenos para evitar um retardo proibitivo Voz 1 2 3 4 5 6 7 8 9 * 8 # PVT Rede de Pacotes PVR 1 2 3 4 5 6 7 8 9 * 8 # PVT 1 2 3 4 5 PVR 1 2 3 4 5 reconstruído Slide 114 Slide 115 Pacotes de vídeo Pacotes de vídeo O fluxo é construído a partir de uma captura que segue um padrão constante de amostragem A exibição também segue um padrão constante MAS a transmissão segue uma taxa variável que depende da taxa de compressão Exemplo: geralmente um vídeo tem uma taxa de captura de 30 quadros por segundo. Se a codificação reduz pouco ou muito a taxa de compressão, isso não implica que a taxa de amostragem não é constante, mas que a taxa de transmissão é variável. Normalmente(se não houver ajuste elástico), a taxa de exibição será a mesma da de captura. Seqüência Quadro Campo Linha Pixel Componente de cor... Bit 101010101010111000111001011 Slide 116 Slide 117
Sistema de transmissão de vídeo Servidores de vídeo Câmera É preciso se preocupar com o armazenamento dos diferentes vídeos A/D Codificador Controle de taxa Adaptador de rede Para a rede Os vídeos mais procurados devem estar em memória Vindo da rede Adaptador de rede Decodificador Controle de Erro D/A Os vídeos menos procurados podem ser armazenados em fita Hierarquia de armazenamento Slide 118 Slide 119 Servidores de vídeo Batching de vídeo Caching O servidor de vídeo mantém em memória principal os últimos vídeos requisitados Proxing Um servidor principal possui várias réplicas de seus vídeos em outros servidores secundários Os servidores secundários podem responder como se fossem o principal Batching O servidor de vídeo não atende a todas as requisições recebidas no instante que elas chegam, para tentar atender a vários clientes As requisições são armazenadas e atendidas apenas em certos períodos de tempo Se houver mais de uma requisição para um mesmo vídeo dentro de um mesmo período de tempo, elas são atendidas com um único fluxo multicast Várias estratégias podem ser adotadas para aperfeiçoar mais o batching Slide 120 Slide 121
Estratégias de batching Aceleração do último requisitante No caso de já haver um fluxo multicast para um vídeo requisitado, iniciar imediatamente um fluxo unicast para esse requisitante com maior taxa de transmissão e incluí- lo no fluxo multicast A idéia é incluir o novo requisitante no fluxo multicast dessa forma Desaleração do fluxo multicast A idéia é a mesma anterior mas diminuindo a taxa de transmissão do fluxo multicast Slide 122