Menu principal
Antigamente, a maioria dos sistemas de live streaming utilizava os protocolos RTSP (Real Time Streaming Protocol) e RTP (Real Time Protocol). Os programas utilizados para reproduzir os conteúdos usavam RTSP para fazer o pedido de streaming ao servidor e, após o pedido ser aceite, entravam em loop para receber os conteúdos enquanto o servidor entrava em loop para os enviar, utilizando o protocolo RTP sobre UDP.
Neste modelo de comunicação RTSP/RTP, é o servidor que decide qual o fragmento do conteúdo que deve ser enviado no próximo momento, baseando-
Posteriormente, começou a ser adoptado o modelo HTTP live streaming. Neste modelo é o programa de reprodução do cliente que controla quando e quais os fragmentos que devem ser enviados por parte do servidor. Actualmente, os sistemas com base neste modelo dispõem de adaptative streaming, isto é, com base na largura de banda disponível e na capacidade do processador do utilizador, o programa de reprodução escolhe a bit rate dos fragmentos a serem pedidos ao servidor. Sendo assim, o servidor tem apenas duas tarefas, codificar o conteúdo a transmitir em tempo real com diferentes qualidades e enviar os fragmentos pedidos pelo cliente. Quando o programa de reprodução contacta pela primeira vez o servidor de streaming, este envia um ficheiro metadata (manifest) contendo os fragmentos disponíveis no servidor quando foi feito o pedido. Os protocolos HLS (HTTP Live Streaming) da Apple, HDS (HTTP Dynamic Streaming) da Adobe, Smooth Streaming da Microsoft e MPEG-
Apple HLS
O HLS permite que o utilizador faça on-
MPEG-
Com o surgimento de várias soluções baseadas em HTTP adaptive live streaming, começaram a surgir vários problemas. O mercado do streaming de conteúdos começou a ficar dividido devido à variedade de soluções, houve um aumento dos custos relativos à capacidade de armazenamento e à largura de banda, sendo claro, o maior prejudicado o cliente. Ficou assim claro que era necessário normalizar o HTTP adaptive streaming. Desta forma nasce o MPEG-
Principais características:
• O manifest é chamado de Media Presentation Description (MPS) e é no formato XML.
• Permite a utilização tanto de MPEG-
• Independência de codecs, isto é, liberdade de escolha para os codecs a utilizar na codificação do áudio e do vídeo.
• Common Encryption, permite a utilização vários métodos de encriptação.
• Podem ser criados vários perfis. Em cada perfil podem-
No entanto, apesar do DASH permitir flexibilidade para a transmissão de conteúdos através de streaming, ainda não é possível saber se vai ser globalmente adoptado ou não, só o tempo o dirá.
Adobe HDS
Mais parecido com o Smooth Streaming que com o HLS. Utiliza ficheiros fragmentados do tipo ISO BMFF como o Smooth Streaming. A principal diferença entre HDS, HLS e Smooth Streaming reside no envio de manifest, o HDS utiliza sequências de números nos pedidos dos fragmentos, assim o cliente não tem que fazer repetidamente download do manifest. Isto faz com que a duração recomendada para os fragmentos em HDS seja entre 2 a 5 segundos.
Microsoft Smooth Streaming
É semelhante ao Apple HLS, mas tem diferenças chave.
Enquanto o HLS cada vez que tem um fragmento novo disponível envia um manifest actualizado para o cliente, o Smooth Streaming utiliza códigos de tempo nos pedidos dos fragmentos. Assim, o cliente não tem que fazer repetidamente download do manifest. Isto faz com que a duração recomendada para os fragmentos em Smooth Streaming seja de 2 segundos, mas em HLS seja de 10 segundos, de forma a diminuir o envio de manifest.
Apesar de ambos utilizarem os codecs H.264 para codificação de vídeo e AAC para codificação de áudio, enquanto o HLS utiliza ficheiros do tipo MPEG-