top of page

Procolocos clássicos

Os protocolos utilizados no mobile video streaming podem ser classificados em três categorias, consoante a sua função: protocolos de rede, de transporte e de sessão.

 

Os protocolos de rede são responsáveis pelo endereçamento e encaminhamento da informação. São exemplos o protocolo de rede IP (Internet Protocol), usado na internet e o ATM (Asynchronous Transfer Mode).

 

Os protocolos de transporte têm como objetivo entregar a informação. Os protocolos de transporte para redes IP são o TCP (Transmission Control Protocol), UDP (User Data Protocol), RTP (Real Transport Protocol) e RTCP (Real-time Transport Control Protocol).

 

Os protocolos de sessão definem as mensagens e procedimentos para estabelecer e controlar a transmissão do conteúdo audiovisual entre o cliente e servidor. São exemplos o RTSP (Real Time Streaming Protocol) .

Estrutura de camadas dos protocolos clássicos

TCP e UDP

A tabela seguinte resume as principais diferenças entre os protocolos de transporte TCP e UDP.

RTP e RTCP

Os protocolos RTP e RTCP são implementados no topo dos protocolos TCP/UDP, fornecendo apenas um conjunto de serviços que suportam o transporte em tempo real de áudio e vídeo. O RTP tem algumas funcionalidades como time-stamping, para a sincronização do áudio e vídeo, atribuição de um número a cada pacote facilitando a deteção de perdas no recetor e identificação da fonte. O RTCP tem como principal objetivo fornecer feedback de QoS aos participantes de uma sessão RTP.

RTSP (Real Time Streaming Protocol)

O RTSP é um protocolo ao nível da aplicação que fornece controlo sobre a entrega de dados em tempo-real. Este protocolo tem por objetivo controlar múltiplas sessões de transmissão de dados, possibilitar a escolha do protocolo de transporte, tal como UDP, multicast UDP ou TCP. As principais funções do protocolo RTSP são o controlo remoto de servidores multimédia, e a inicialização e manutenção de sessões [7]. Este protocolo não tem interferência no transporte dos dados, deixando essas funções para outros protocolos, normalmente o RTP. Uma grande desvantagem deste protocolo é o facto de as suas transmissões serem muitas vezes bloqueadas por routers e firewalls [6].

Comunicação servidor-utilizador utilizando RTSP

HTTP based protocols

Porém os protocolos anteriormente descritos são já considerados os clássicos protocolos de streaming. A nova tendência no streaming é utilizar tecnologias de streaming adaptativo, que utilizam o protocolo HTTP. O HTTP é um protocolo stateless, utiliza um débito binário adaptativo, ao contrário do que acontecia com os protocolos clássicos em que a velocidade de stream era a velocidade de codificação. Também a entrega baseada em HTTP não tem quaisquer problemas de firewalls ou routers, nem requer proxies, caches ou servidores especiais. É o programa de reprodução do cliente que controla o débito binário dos fragmentos a serem pedidos ao servidor, que depende da largura de banda e capacidade de processador do cliente. Algumas destas tecnologias, que se focam na ideia de utilizar a mesma infraestrutura que a implementada na internet são o HLS (HTTP Live Streaming), da Apple, HDS (HTTP Dynamic Streaming), da Adobe e Smooth Streaming, da Microsoft.

HTTP Live Streaming

O HLS permite enviar transmissões ao vivo ou pré-gravadas através de HTTP, a partir de um servidor web comum para dispositivos iOS. O conteúdo é codificado (o vídeo com H.264 e o áudio com MP3 ou AAC) e sementado no server e a distribuição é feita através de um servidor web ou sistema de cache web, . O servidor pode conter várias versões dos segmentos de vídeo em diferentes formatos. Desta forma, os terminais móveis com maior largura de banda disponível podem utilizar versões com qualidade superior relativamente aos terminais com menor largura de banda disponível, por exemplo o Wi-Fi. Há portanto um ajuste dinâmico da qualidade do vídeo para assegurar uma visualização contínua do conteúdo [8].

Configuração do streaming HLS [8]

HTTP Dynamic Streaming

O HO HDS permite a entrega de vídeo pré-gravado ou ao vivo com um débito binário adaptativo, através de conexões HTTP regulares. Aproveita as infraestruturas de cache existentes [9]. A figura abaixo demonstra o processo desde a preparação do vídeo até ao consumo num dispositivo móvel. Tal como no protocolo RTSP/RTP também no HDS existe comunicação servidor/cliente. Quer o cliente quer o servidor sabem a largura de banda do cliente, pelo que ambos podem adaptar o vídeo a transmitir.

Preparação, distribuição, proteção e consumo de vídeo através de HDS [3]

Smooth Streaming

O Smooth Streaming tem uma implementação baseada na entrega HTTP adaptativa. Ao contrário de outras soluções, esta não divide os ficheiros originais fisicamente, ou seja, no servidor, em vez de estarem guardados pequenos ficheiros para cada conteúdo, estão guardados os ficheiros completos. A divisão é feita virtualmente consoante a largura de banda e processador do utilizador, melhorando significativamente o processo de gestão de ficheiros. Existem ainda ficheiros com diversas qualidades para que haja adaptação da qualidade do vídeo ao estado da rede móvel. Usa a plataforma IIS, Internet Information Services, também esta baseada em http [10].

Arquitetura do smooth streaming [10]

MPEG-Dash

O MPEG-Dash surgiu da necessidade de haver interoperabilidade entre os servidores e clientes de diferentes fornecedores. O conteúdo existe no servidor  em duas partes: Media Presentation Description (MPD) e os segmentos que incluem os diferentes débitos binários do conteúdo, sob a forma de pedaços. Para reproduzir o conteúdo, primeiro o cliente recebe o MPD, ficando a saber todas as características do conteúdo, como por exemplo a resolução do vídeo. Com estas informações o cliente DASH começa a transmissão de conteúdo usando solicitações HTTP GET, monitorando variações da largura de banda disponível, tirando do servidor segmentos com diferentes débitos binários [11].

Arquitetura MPEG-DASH [11]

Ver outras tecnologias

bottom of page